[infinispan-dev] hotrod client - initial connection

[Galder Zamarreno]

On Wed, 10 Mar 2010 14:47:29 +0100, Manik Surtani <manik at jboss.org> wrote:

>
> On 10 Mar 2010, at 13:08, Mircea Markus wrote:
>
>> Hi Galder,
>>
>> Here are some thoughts I have about how the hotrod client performs  
>> initial connection to the HR servers:
>> A list of servers is statically configured so that the client can  
>> connect to any of them
>>             1. client will ping each configured server until it finds  
>> one that is up and running
>>             2. at this point it will stop(i.e. not query other  
>> statically configured servers) and query this server for the cluster  
>> topology
>>             3. a a response to this query, the server informs the  
>> client about hotrod cluster topology (which might be different than  
>> infinispan cluster, right?)
>>             4. based on this information client builds a pool of  
>> connections to the servers
>>             5. client register itself as cluster formation listener,  
>> and update the list of active servers whenever the topology changes
>> (cluster formation might not be the best name for this listener as it  
>> only refers to the time when cluster is formed, what about cluster  
>> topology listener?)
>> How does this sound to you?
>> Also, a question about the way in which the server notifies the client  
>> on topology changes: how is this going to be performed network-wise?  
>> Some of the approaches I see are:
>> - serv socket opened on the client, server connects to it. Advantage:  
>> immediate notification on change. Disadvantage: network security  
>> issues, firewall. (also very uncommon for clients to do that, afaik)
>> - A thread on the client constantly pings the server and the new  
>> topology (if any is piggybacked). This would increase the latency, but  
>> will solve the firewall issues
>> - on each request, we piggyback this info, if needed
>
> The last one is the correct approach.  The second one could be  
> implemented as an option, but probably later on if there is sufficient  
> demand.  The first approach is definitely a no-go - much too complex if  
> the server needs to maintain open connections to each and every client.

Guys, am I missing something here? Didn't we agree on this email thread  
that we wouldn't be piggybacking this information with each request?

See outcome of  
http://lists.jboss.org/pipermail/infinispan-dev/2010-January/002183.html  
that ends with a +1 from Manik:  
http://lists.jboss.org/pipermail/infinispan-dev/2010-January/002213.html

We had thought of piggybacking at the beginning and based on Alex's  
feedback, we decided clients would register and the servers would send  
events to them. See "Event Handling" section in the wiki:  
http://community.jboss.org/wiki/HotRodProtocol#Event_Handling that  
explains the only way cluster formation changes will be sent around. This  
has been present in this format since almost 2 months ago.

Mircea, I think it would help to read previous discussions of the protocol  
to understand better the rationale behing the protocol specification.

>
> Cheers
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache