On Nov 26, 2013, at 3:49 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
On Nov 19, 2013, at 2:49 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
> Nice work!
>
> Few questions:
> - in the context of near-caching, entry-modified and entry-deleted would have the
same effect on the client: invalidation of data. If near-caching is our main goal, we
might as well send a single notification type (entry-modified) for both modification and
deletion (the deletion is just a particular case of modification). Just an idea.
There's a difference between an update and a delete. The update can carry the latest
version of the entry in memory, which could be of use to the client, if for example they
want to do a replace() as long as the version has not changed. The delete would not have
that info since the entry is gone. I think it's more logical to have both separate.
indeed.
> - 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. 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?
Cheers,
>
>
> On Nov 12, 2013, at 3:17 PM, Galder Zamarreño <galder(a)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(a)redhat.com
>>
twitter.com/galderz
>>
>> Project Lead, Escalante
>>
http://escalante.io
>>
>> Engineer, Infinispan
>>
http://infinispan.org
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)