On Dec 2, 2013, at 10:00 AM, Dan Berindei <dan.berin...@gmail.com> wrote:
> > On Mon, Dec 2, 2013 at 11:44 AM, Galder Zamarreño <gal...@redhat.com> wrote: > > On Nov 27, 2013, at 3:06 PM, Mircea Markus <mmar...@redhat.com> wrote: > > > > >> > >>> - how does the server know that a request originated from a certain > >>> client in order not to send it to that client again? There's no clientId > >>> in the request… > >> > >> Well spotted :). There are two ways to solve this. > >> > >> First one is by adding the source id to each cache operation sent from the > >> client. This would require a change in the way the header is parsed for > >> all operations. This is the simplest solution, with a little addition to > >> the header. > >> > >> The second option is a bit more complicated but avoids the need to send > >> the source id per request. At least in the Java client, each connection > >> opened sends a ping at the start. You could add source id to the ping > >> command, and then the server could track all incoming connections that > >> send a particular id. There could be multiple in the case of clients > >> pooling connections. The server can track disconnections and keep this > >> collection up to date, but it'd be quite a bit of work on top of the rest > >> of stuff. > >> > >> I'd prefer the first option. > > > > +1, for simplicity. We also don't enforce the client connections to start > > with a ping either. > > ^ Indeed we don't. It's something the java client does by default but it's > not mandatory at all. > > > How would you generate the client id? ip+port perhaps? or something the > > server would issue (shared server counter) when a client asks for it? > > The client or source id should ideally be composed of two parts: > 1. Something the Hot Rod client provides via configuration. > 2. Something that's dynamically generated whenever the RemoteCacheManager is > started. > > The former could be anything from a simple application id, to an application > id alonside client host and port. This is the static part of the source or > client id. The one that's always the same for a RemoteCacheManager unless the > configuration changes. The second part, which is dynamic, should be created > by the Hot Rod client implementation in order to avoid client resurrection > issues (a similar method to what JGroups does). > > Regardless, the source or client id will be a variable length byte array. > > I think this is easier than relying in some kind of server side state, and > having to synch that. You could have many clients connecting, so having to > produce something different for each, cluster wide, could be challenging. > > Thoughts? > > Why not a UUID? +1. It is a bit large but I think it would do in the first iteration. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
