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? > > > > >> > >> Cheers, > >> > >>> > >>> > >>> On Nov 12, 2013, at 3:17 PM, Galder Zamarreño <gal...@redhat.com> > wrote: > >>> > >>>> Hi all, > >>>> > >>>> Re: > https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events > >>>> > >>>> I've just finished writing up the Hot Rod remote events design > document. Amongst many other use cases, this will enable near caching use > cases with the help of Hot Rod client callbacks. > >>>> > >>>> Cheers, > >>>> -- > >>>> Galder Zamarreño > >>>> gal...@redhat.com > >>>> twitter.com/galderz > >>>> > >>>> Project Lead, Escalante > >>>> http://escalante.io > >>>> > >>>> Engineer, Infinispan > >>>> http://infinispan.org > >>>> > >>>> > >>>> _______________________________________________ > >>>> infinispan-dev mailing list > >>>> infinispan-dev@lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>> > >>> 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 > >> > >> > >> -- > >> Galder Zamarreño > >> gal...@redhat.com > >> twitter.com/galderz > >> > >> Project Lead, Escalante > >> http://escalante.io > >> > >> Engineer, Infinispan > >> http://infinispan.org > >> > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > 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 > > > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev