[infinispan-dev] Design of Remote Hot Rod events

[Dan Berindei]

On Mon, Dec 2, 2013 at 11:44 AM, Galder Zamarreño <galder at redhat.com> wrote:

>
> On Nov 27, 2013, at 3:06 PM, Mircea Markus <mmarkus at 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 <galder at 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
> >>>> galder at redhat.com
> >>>> twitter.com/galderz
> >>>>
> >>>> Project Lead, Escalante
> >>>> http://escalante.io
> >>>>
> >>>> Engineer, Infinispan
> >>>> http://infinispan.org
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> infinispan-dev at 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 at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >>
> >> --
> >> Galder Zamarreño
> >> galder at redhat.com
> >> twitter.com/galderz
> >>
> >> Project Lead, Escalante
> >> http://escalante.io
> >>
> >> Engineer, Infinispan
> >> http://infinispan.org
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131202/8fcbd3c1/attachment-0001.html