Hi all, I have completed implementation of this component, and the relevant PR may be found at [1].
If I explain the mechanism a bit, an mDNS service is registered for the Thrift server (i.e. DAS, CEP or product-analytics distributions), provided that a system flag "receiverDiscoveryEnabled" is set. The service will be automatically maintained per each network interface found on the server node (since as explained above, we cannot infer the network interface(s) reachable from outside the node/LAN). A Thrift client (in this case, the EventStreamService OSGi service which is our recommended way of publishing data to DAS/CEP/product-analytics), if started with the same flag, is then able to discover the above service, and it will resolve the first available Thrift endpoint through multicast DNS. Then, its local configuration will be overwritten with the discovered Thrift endpoint (with a log printed stating this fact). The client is then able to send events to the Thrift server with zero configuration from the user's part. Questions/comments welcome. Thanks, [1] https://github.com/wso2/carbon-analytics-common/pull/270 On 30 June 2016 at 16:49, Gokul Balakrishnan <[email protected]> wrote: > Sure Srinath. However, prior to committing, there are a few concerns with > the approach which I think should be considered: most importantly, how we > should resolve the hostname/IP of the Thrift server. Currently, the Thrift > server is set to listen to all interfaces for incoming connections > (0.0.0.0), whether valid or not. This is to overcome the earlier issues > we've had where the Thrift server would bind to the first Network interface > it found. > > On the server side, we will need to initialize the service discovery to a > specific network interface which is also capable of accepting Thrift > connections. The issue is that it's not possible to always guarantee that > this interface is reachable from outside the local machine or LAN. For > instance, the IP that we've bound to the multicast service could be from a > virtual network interface. Normally, within a single node, this will not > pose an issue, but overcoming this issue in a multi-node environment will > mean maintaining a configuration which points to the correct IP which could > accept incoming Thrift connections from outside the node (since we can't > infer this information from the Thrift server, as it's already bound to ALL > interfaces). This of course will negate our goal of zero configuration. > > The alternative is to let the analytics (server) node provide the list of > ALL its network interfaces to the client and the client then going through > them one by one to try and create a socket connection, to see if one or > more them is accepting Thrift connections. This is not desirable due to > obvious reasons. > > How shall we proceed? > > Thanks, > > On 30 June 2016 at 08:52, Srinath Perera <[email protected]> wrote: > >> Thanks, sound good. Please do ASAP. We are at beta, so too late even now. >> >> --Srinath >> >> On Thu, Jun 30, 2016 at 8:09 AM, Gokul Balakrishnan <[email protected]> >> wrote: >> >>> Hi Srinath, >>> >>> As per our offline chat earlier, the initial plan is to locate >>> the Thrift endpoint through mDNS service discovery, considering the host >>> and port first. >>> >>> I have used the JmDNS library pointed by Nirmal to do a PoC on this >>> scenario, and I've also already incorporated the logic into the databridge >>> Thrift server to enable service registration through a system property the >>> users could set (-DenableDiscovery). The corresponding client code goes >>> into the publisher OSGi service initialisation. This too is controllable by >>> the same system property the user could set on the Thrift client (which >>> will be the product talking to DAS/CEP). >>> >>> I'm doing some testing on the entire scenario, and once completed, I'll >>> commit the changes into the relevant repos and send an update to this >>> thread. >>> >>> Thanks, >>> >>> >>> On Thursday, 30 June 2016, Srinath Perera <[email protected]> wrote: >>> >>>> Resending as it hits a filter rule. >>>> >>>> Gokul, please give an update on this? >>>> >>>> --Srinath >>>> >>> >>> >>> -- >>> Gokul Balakrishnan >>> Senior Software Engineer, >>> WSO2, Inc. http://wso2.com >>> M +94 77 5935 789 | +44 7563 570502 >>> >>> >>> >> >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> http://people.apache.org/~hemapani/ >> http://srinathsview.blogspot.com/ >> > > > > -- > Gokul Balakrishnan > Senior Software Engineer, > WSO2, Inc. http://wso2.com > M +94 77 5935 789 | +44 7563 570502 > > -- Gokul Balakrishnan Senior Software Engineer, WSO2, Inc. http://wso2.com M +94 77 5935 789 | +44 7563 570502
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
