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 <srin...@wso2.com> 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 <go...@wso2.com> > 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 <srin...@wso2.com> 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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
