4:17 p.m.
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
11:33 a.m.
Hi, my couple of questions & remarks:
1. Why there is no RemoteCacheEntryCreated? I guess you had good reason
to exclude it but you could at least explain it. For the event lifecycle
creation sounds to me as important as removal.
2. Does removal due to expiration map to Removed as well? What about
invalidation in invalidation cache?
3. IMO, registering events for particular keys is not that optional. If
you allow only all-keys listener, you end up with users screwing
performance by registering listeners with if (key.equals(myKey)) {...}.
4. It seems to me that one global listener per client per cache is
enough. Will the client code register such single listener and multiplex
all the events to the registered listeners? Related to 3. if you don't
implement the filtering by key on server, you should at least already
provide this as client API and do the equals check locally.
Nevertheless, this would require client equality on keys.
5. Are pre/post events supported here? I guess not, but this is
something to note.
6. Are the events in fact async? It seems to me that these are (the ACKs
are only for delivery).
7. The reliability guarantees should be specified more closely. From the
document it seems that we try to support the near-cache use case by
always sending the last update (the intermediate updates can be lost
according to ACK tracking), but the events themselves are not guaranteed
to be delivered. So is the target reliability "eventually synced cache"?
8. As the client itself is responsible for contacting each server and
registering the listener, there's another scenario besides server
failure. It takes some time before client receives new topology, so
another server might join and become primary owner - the client does not
register to that server until it's late and does not receive the update.
Even after the client joins, the server has not tracked the listener and
can't see that it should send the update.
Solution for this would be to keep a cache of listeners (replicated for
global ones, distributed for key-filtered), delay all writes until this
cache is replicated and then keep the event in memory even if the client
is not yet connected.
Radim
On 11/12/2013 04:17 PM, Galder Zamarreño 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
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
4:10 p.m.
Hi Radim,
Thanks for the excellent feedback, comments below:
On Nov 13, 2013, at 11:33 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
Hi, my couple of questions & remarks:
1. Why there is no RemoteCacheEntryCreated? I guess you had good reason
to exclude it but you could at least explain it. For the event lifecycle
creation sounds to me as important as removal.
When designing this, I looked at the near cache use case as main drive (doesn't mean
there aren't others, but it's the most obvious one IMO). For near caches, updates
and removals are crucial. IOW, you could not build a near cache without receiving
notification of those. Creation could be a "nice to have", so that clients can
lazily fetch newly created entries in advance, but it could be wasteful if the client does
not request those cached data.
"If in doubt, leave it out" <- I applied that principle, but I'm happy to
add create events if I hear about a use case that must have them. As a side note, we could
make this more sophisticated by allowing the clients to express what operations
they're interested in, potentially allowing those that are interested in created
events to receive them. This would help with reducing unnecessary traffic, i.e. by not
receiving notifications for those events not interested, but I wanted to keep it simple to
start with.
2. Does removal due to expiration map to Removed as well? What about
invalidation in invalidation cache?
Removal notifications based on expiration are tricky, particularly for the implications it
has on plugged caches stores. See discussion [1]. These are not yet available for embedded
caches, so we'd need to tackle that first before adding them for remote events.
Invalidation in invalidated caches are really normal removes sent to other nodes, so
events would be produced then.
3. IMO, registering events for particular keys is not that optional.
If
you allow only all-keys listener, you end up with users screwing
performance by registering listeners with if (key.equals(myKey)) {…}.
Yeah, if users do that, there's a lot of traffic wasted, but again, I had the near
cache use case in mind where you're interested in all data in the cache, as opposed to
a subset. However, it could be added to the design.
4. It seems to me that one global listener per client per cache is
enough. Will the client code register such single listener and multiplex
all the events to the registered listeners? Related to 3. if you don't
implement the filtering by key on server, you should at least already
provide this as client API and do the equals check locally.
Nevertheless, this would require client equality on keys.
Not sure I understand your point ^.
5. Are pre/post events supported here? I guess not, but this is
something to note.
No, there won't be pre/post events. Too much traffic. There will only be post events.
6. Are the events in fact async? It seems to me that these are (the
ACKs
are only for delivery).
Of course, we can't afford to have a server thread blocked waiting for an ACK from the
client.
7. The reliability guarantees should be specified more closely. From the
document it seems that we try to support the near-cache use case by
always sending the last update (the intermediate updates can be lost
according to ACK tracking), but the events themselves are not guaranteed
to be delivered. So is the target reliability "eventually synced cache"?
Yeah, that's the idea. It's a trade off I made in order to avoid overloading
clients when they've been disconnected.
8. As the client itself is responsible for contacting each server and
registering the listener, there's another scenario besides server
failure. It takes some time before client receives new topology, so
another server might join and become primary owner - the client does not
register to that server until it's late and does not receive the update.
Even after the client joins, the server has not tracked the listener and
can't see that it should send the update.
Solution for this would be to keep a cache of listeners (replicated for
global ones, distributed for key-filtered), delay all writes until this
cache is replicated and then keep the event in memory even if the client
is not yet connected.
That's certainly an interesting scenario. I'm not sure there's a need for
replicaed/distributed cache at all here. In fact, in the design I've done I've
tried to avoid any type of clustered state for this work. Any new joining node could keep
a buffer of events for a X amount of time to allow all clients to have the time to
register their listeners with the new server and receive events in case they are late.
Cheers,
[1] https://issues.jboss.org/browse/ISPN-694
Radim
On 11/12/2013 04:17 PM, Galder Zamarreño 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
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
_______________________________________________
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
10:57 a.m.
On 11/26/2013 04:10 PM, Galder Zamarreño wrote:
Hi Radim,
Thanks for the excellent feedback, comments below:
On Nov 13, 2013, at 11:33 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
> Hi, my couple of questions & remarks:
>
> 1. Why there is no RemoteCacheEntryCreated? I guess you had good reason
> to exclude it but you could at least explain it. For the event lifecycle
> creation sounds to me as important as removal.
When designing this, I looked at the near cache use case as main drive (doesn't mean
there aren't others, but it's the most obvious one IMO). For near caches, updates
and removals are crucial. IOW, you could not build a near cache without receiving
notification of those. Creation could be a "nice to have", so that clients can
lazily fetch newly created entries in advance, but it could be wasteful if the client does
not request those cached data.
"If in doubt, leave it out" <- I applied that principle, but I'm happy
to add create events if I hear about a use case that must have them. As a side note, we
could make this more sophisticated by allowing the clients to express what operations
they're interested in, potentially allowing those that are interested in created
events to receive them. This would help with reducing unnecessary traffic, i.e. by not
receiving notifications for those events not interested, but I wanted to keep it simple to
start with.
I often think about ispn as a shared memory, providing communication
between nodes. Messaging would be probably more fitting for such
use-case, but I can imagine the listener waiting for some value to be
inserted to the cache.
Nevertheless, you can always use putIfAbsent(K, DummyValue) and wait for
the modification.
> 2. Does removal due to expiration map to Removed as well? What about
> invalidation in invalidation cache?
Removal notifications based on expiration are tricky, particularly for the implications
it has on plugged caches stores. See discussion [1]. These are not yet available for
embedded caches, so we'd need to tackle that first before adding them for remote
events.
Invalidation in invalidated caches are really normal removes sent to other nodes, so
events would be produced then.
> 3. IMO, registering events for particular keys is not that optional. If
> you allow only all-keys listener, you end up with users screwing
> performance by registering listeners with if (key.equals(myKey)) {…}.
Yeah, if users do that, there's a lot of traffic wasted, but again, I had the near
cache use case in mind where you're interested in all data in the cache, as opposed to
a subset. However, it could be added to the design.
I can imagine the near cache to be caching only events the client was
previously interested in. You don't want to cache all the petabytes of
data Infinispan will cache in the cluster, on one client. That does not
scale, and Infinispan is all about scaling.
Besides that, being interested in all data and not providing the CREATE
event seems somewhat contradictory to me.
> 4. It seems to me that one global listener per client per cache is
> enough. Will the client code register such single listener and multiplex
> all the events to the registered listeners? Related to 3. if you don't
> implement the filtering by key on server, you should at least already
> provide this as client API and do the equals check locally.
> Nevertheless, this would require client equality on keys.
Not sure I understand your point ^.
The application could register multiple identical listeners. If the
client code was dumb, it would register the same listener twice on
server -> send notifications twice -> redundant traffic & processing on
both client and server.
Let's decide whether it's a responsibility of application code to evade
this scenario or if the client should do that.
> 5. Are pre/post events supported here? I guess not, but this is
> something to note.
No, there won't be pre/post events. Too much traffic. There will only be post
events.
> 6. Are the events in fact async? It seems to me that these are (the ACKs
> are only for delivery).
Of course, we can't afford to have a server thread blocked waiting for an ACK from
the client.
> 7. The reliability guarantees should be specified more closely. From the
> document it seems that we try to support the near-cache use case by
> always sending the last update (the intermediate updates can be lost
> according to ACK tracking), but the events themselves are not guaranteed
> to be delivered. So is the target reliability "eventually synced cache"?
Yeah, that's the idea. It's a trade off I made in order to avoid overloading
clients when they've been disconnected.
> 8. As the client itself is responsible for contacting each server and
> registering the listener, there's another scenario besides server
> failure. It takes some time before client receives new topology, so
> another server might join and become primary owner - the client does not
> register to that server until it's late and does not receive the update.
> Even after the client joins, the server has not tracked the listener and
> can't see that it should send the update.
> Solution for this would be to keep a cache of listeners (replicated for
> global ones, distributed for key-filtered), delay all writes until this
> cache is replicated and then keep the event in memory even if the client
> is not yet connected.
That's certainly an interesting scenario. I'm not sure there's a need for
replicaed/distributed cache at all here. In fact, in the design I've done I've
tried to avoid any type of clustered state for this work. Any new joining node could keep
a buffer of events for a X amount of time to allow all clients to have the time to
register their listeners with the new server and receive events in case they are late.
OK, keeping some history would solve that as well.
Now, as there will be some code feeding the client with updates, I think
that information about topology change should go through that channel as
well in order to reduce the history period.
Radim
Cheers,
[1] https://issues.jboss.org/browse/ISPN-694
> Radim
>
>
> On 11/12/2013 04:17 PM, Galder Zamarreño 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
>
> --
> Radim Vansa <rvansa(a)redhat.com>
> JBoss DataGrid QA
>
> _______________________________________________
> 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
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
4:44 p.m.
On Dec 2, 2013, at 10:57 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
On 11/26/2013 04:10 PM, Galder Zamarreño wrote:
> Hi Radim,
>
> Thanks for the excellent feedback, comments below:
>
> On Nov 13, 2013, at 11:33 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
>
>
>> 3. IMO, registering events for particular keys is not that optional. If
>> you allow only all-keys listener, you end up with users screwing
>> performance by registering listeners with if (key.equals(myKey)) {…}.
> Yeah, if users do that, there's a lot of traffic wasted, but again, I had the
near cache use case in mind where you're interested in all data in the cache, as
opposed to a subset. However, it could be added to the design.
I can imagine the near cache to be caching only events the client was
previously interested in. You don't want to cache all the petabytes of
data Infinispan will cache in the cluster, on one client. That does not
scale, and Infinispan is all about scaling.
^ It's common for near caches to have an agressive eviction policy.
Besides that, being interested in all data and not providing the
CREATE
event seems somewhat contradictory to me.
>
>> 4. It seems to me that one global listener per client per cache is
>> enough. Will the client code register such single listener and multiplex
>> all the events to the registered listeners? Related to 3. if you don't
>> implement the filtering by key on server, you should at least already
>> provide this as client API and do the equals check locally.
>> Nevertheless, this would require client equality on keys.
> Not sure I understand your point ^.
The application could register multiple identical listeners. If the
client code was dumb, it would register the same listener twice on
server -> send notifications twice -> redundant traffic & processing on
both client and server.
Let's decide whether it's a responsibility of application code to evade
this scenario or if the client should do that.
True. I don't have an answer for that yet.
How doable that is might depend on how clients maintain listener information.
It's an interesting edge case for sure.
>
>
>> 8. As the client itself is responsible for contacting each server and
>> registering the listener, there's another scenario besides server
>> failure. It takes some time before client receives new topology, so
>> another server might join and become primary owner - the client does not
>> register to that server until it's late and does not receive the update.
>> Even after the client joins, the server has not tracked the listener and
>> can't see that it should send the update.
>> Solution for this would be to keep a cache of listeners (replicated for
>> global ones, distributed for key-filtered), delay all writes until this
>> cache is replicated and then keep the event in memory even if the client
>> is not yet connected.
> That's certainly an interesting scenario. I'm not sure there's a need for
replicaed/distributed cache at all here. In fact, in the design I've done I've
tried to avoid any type of clustered state for this work. Any new joining node could keep
a buffer of events for a X amount of time to allow all clients to have the time to
register their listeners with the new server and receive events in case they are late.
OK, keeping some history would solve that as well.
^ A better way to solve this is by maintaining listener information cluster wide, which
we'll have as a result of clustered listeners. This way, clients do not need to
re-register when a new node joins in. See side note in [1]
[1] http://lists.jboss.org/pipermail/infinispan-dev/2013-November/014230.html
Now, as there will be some code feeding the client with updates, I
think
that information about topology change should go through that channel as
well in order to reduce the history period.
Nice to have, but out of the scope of this. Hot Rod will reuse the same channels that
client opened in order to send the updates. Although topology changes could be handled in
the same way too, I don't expect to apply that change at this stage.
Cheers,
Radim
>
> Cheers,
>
> [1] https://issues.jboss.org/browse/ISPN-694
>
>> Radim
>>
>>
>> On 11/12/2013 04:17 PM, Galder Zamarreño 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
>>
>> --
>> Radim Vansa <rvansa(a)redhat.com>
>> JBoss DataGrid QA
>>
>> _______________________________________________
>> 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
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
_______________________________________________
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
2:49 a.m.
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.
- 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...
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)
4:49 p.m.
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.
- 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.
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
3:06 p.m.
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)
10:44 a.m.
On Nov 27, 2013, at 3:06 PM, Mircea Markus <mmarkus(a)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?
>
> 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)
_______________________________________________
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
11 a.m.
On Mon, Dec 2, 2013 at 11:44 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
On Nov 27, 2013, at 3:06 PM, Mircea Markus <mmarkus(a)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(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)
>
>
>
>
>
> _______________________________________________
> 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
12:44 p.m.
On Dec 2, 2013, at 10:00 AM, Dan Berindei <dan.berindei(a)gmail.com> wrote:
On Mon, Dec 2, 2013 at 11:44 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
On Nov 27, 2013, at 3:06 PM, Mircea Markus <mmarkus(a)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)
9:48 a.m.
Hey there,
Here are a few comments based on a quick reading.
I might have totally misread or misinterpreted what was exposed, feel
free to correct me.
## General
I think you are restricting the design to listeners:
* that only listen to raw entry changes
* whose processing is remote
* with no way to filter out the event from the server
Is that correct? I can see that it does address the remote L1 use case
but I feel like it will close the doors to many more use cases. An
interesting example being continuous query.
In that use case the listener code runs a filtering logic server side
and only send keys that are impacted by the query plus some flag
defining whether it's added to changed or removed from the corpus.
The key is filtering event before sending it to the client.
I wish the design document was showing how we can achieve a general
purpose remote listener approach but have a step 1 that is only
targeting a restricted set of listeners if you feel that it's too much
to chew. I don't want us to be trapped in a situation where backward
compatibility prevent us from adding use cases.
## Specific questions
When the topology changes, it is the responsibility of the client to add
the listener to the new servers that show up. Correct? The API is a
global addRemoteListener but I imagine the client implementation will
have to transparently deal with that.
I wonder if a server approach is not more convinient. At least it does
not put the burden and bugs in several implementations and several
languages.
You never send code at the moment. Only one kind of listener is
available and listeners to all entry change and deletion. Correct?
Why not have the ability to listen to new entry events? That would limit
generic listeners as it is.
Do you have plans to make the ACK optional depending on the listener
requirement? Looks like an expensive process.
"Only the latest event is tracked for ACK for a given key"
It seems it's fine for L1 but would be a problem for many more generic
listeners.
Emmanuel
On Tue 2013-11-12 16:17, Galder Zamarreño 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
12:23 p.m.
On 11/19/2013 09:48 AM, Emmanuel Bernard wrote:
Hey there,
Here are a few comments based on a quick reading.
I might have totally misread or misinterpreted what was exposed, feel
free to correct me.
## General
I think you are restricting the design to listeners:
* that only listen to raw entry changes
* whose processing is remote
* with no way to filter out the event from the server
Is that correct? I can see that it does address the remote L1 use case
but I feel like it will close the doors to many more use cases. An
interesting example being continuous query.
Please, use the term "near
cache" rather than "remote L1". L1 is rather
ambiguous as it already represents L1 cache and L1 HotRod intelligence
level.
In that use case the listener code runs a filtering logic server side
and only send keys that are impacted by the query plus some flag
defining whether it's added to changed or removed from the corpus.
The key is filtering event before sending it to the client.
I wish the design document was showing how we can achieve a general
purpose remote listener approach but have a step 1 that is only
targeting a restricted set of listeners if you feel that it's too much
to chew. I don't want us to be trapped in a situation where backward
compatibility prevent us from adding use cases.
I was also suggesting that listener
on particular key should be
mandatory requirement. However, any general server-side filtering logic
would be hard to specify as HotRod is language-unaware binary protocol.
Therefore, the best you could get is some kind of binary regular
expressions. For the start, global/one-key filtering is a good start and
the door are not closed for any further options.
## Specific questions
When the topology changes, it is the responsibility of the client to add
the listener to the new servers that show up. Correct? The API is a
global addRemoteListener but I imagine the client implementation will
have to transparently deal with that.
I wonder if a server approach is not more convinient. At least it does
not put the burden and bugs in several implementations and several
languages.
+1
You never send code at the moment. Only one kind of listener is
available and listeners to all entry change and deletion. Correct?
Why not have the ability to listen to new entry events? That would limit
generic listeners as it is.
Do you have plans to make the ACK optional depending on the listener
requirement? Looks like an expensive process.
"Only the latest event is tracked for ACK for a given key"
It seems it's fine for L1 but would be a problem for many more generic
listeners.
Emmanuel
Radim
On Tue 2013-11-12 16:17, Galder Zamarreño 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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
2:01 p.m.
On Tue 2013-11-19 12:23, Radim Vansa wrote:
On 11/19/2013 09:48 AM, Emmanuel Bernard wrote:
> I wish the design document was showing how we can achieve a general
> purpose remote listener approach but have a step 1 that is only
> targeting a restricted set of listeners if you feel that it's too much
> to chew. I don't want us to be trapped in a situation where backward
> compatibility prevent us from adding use cases.
I was also suggesting that listener on particular key should be
mandatory requirement. However, any general server-side filtering logic
would be hard to specify as HotRod is language-unaware binary protocol.
Therefore, the best you could get is some kind of binary regular
expressions. For the start, global/one-key filtering is a good start and
the door are not closed for any further options.
Well
1. you have a query language that can express restriction regardless of
your target client language
2. one can imagine to separate the notion of listener *type* whose
implementation is registered on the server and a given client activating
a given listener type with some primitive parameters is possible
2:15 p.m.
On 11/19/2013 02:01 PM, Emmanuel Bernard wrote:
On Tue 2013-11-19 12:23, Radim Vansa wrote:
> On 11/19/2013 09:48 AM, Emmanuel Bernard wrote:
>> I wish the design document was showing how we can achieve a general
>> purpose remote listener approach but have a step 1 that is only
>> targeting a restricted set of listeners if you feel that it's too much
>> to chew. I don't want us to be trapped in a situation where backward
>> compatibility prevent us from adding use cases.
> I was also suggesting that listener on particular key should be
> mandatory requirement. However, any general server-side filtering logic
> would be hard to specify as HotRod is language-unaware binary protocol.
> Therefore, the best you could get is some kind of binary regular
> expressions. For the start, global/one-key filtering is a good start and
> the door are not closed for any further options.
Well
1. you have a query language that can express restriction regardless of
your target client language
I'd rather see this kind of functionality within
remote continuous
queries than as a part of the listeners API. Mixing the listeners API
(which I'd consider as "basic") and query where you require all the
protobuf-stuff.
2. one can imagine to separate the notion of listener *type* whose
implementation is registered on the server and a given client activating
a given listener type with some primitive parameters is possible
That sounds to me
as more viable option, thanks for pointing it out.
Radim
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
8:41 a.m.
On Nov 19, 2013, at 12:23 PM, Radim Vansa <rvansa(a)redhat.com> wrote:
On 11/19/2013 09:48 AM, Emmanuel Bernard wrote:
> </snip>
>
> In that use case the listener code runs a filtering logic server side
> and only send keys that are impacted by the query plus some flag
> defining whether it's added to changed or removed from the corpus.
> The key is filtering event before sending it to the client.
>
> I wish the design document was showing how we can achieve a general
> purpose remote listener approach but have a step 1 that is only
> targeting a restricted set of listeners if you feel that it's too much
> to chew. I don't want us to be trapped in a situation where backward
> compatibility prevent us from adding use cases.
I was also suggesting that listener on particular key should be
mandatory requirement. However, any general server-side filtering logic
would be hard to specify as HotRod is language-unaware binary protocol.
Therefore, the best you could get is some kind of binary regular
expressions. For the start, global/one-key filtering is a good start and
the door are not closed for any further options.
Ideally, all filtering should probably be done server, both for type of operation and
per-key filtering. If as you rightly say, some client cannot apply filtering per-key
cleanly on the server side, they can always apply filtering client-side based on a client
specific implementation, but that should be last resort.
Per-cache operation filtering should really be done server side.
Cheers,
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
1:17 p.m.
Dear Galder,
I have read with great interest the design document your wrote for Hot
Rod remote eventing [1].
In the perspective of the LEADS project, that aims at building a
continuous query/streaming engine on top of Infinispan, this new feature
seem very promising. However, it seems that in the current design their
is no mean to ensure dependability, i.e., the property that once
registered for a key k, a client will never miss an event regarding k,
even if the primary server in charge of k fails. How difficult do you
think it would be to ensure this ?
Besides, following Emmanuel's opinion, I believe that it would be useful
to notify a client on a new cache insertion and to allow it to set-up
filters on the servers (this last point is part of your clustered
listeners design document [2] but I do not know if you plan to
incorporate it to Hot-Rod).
Thank you in advance for your answers,
Best,
Pierre
[1] https://github.com/infinispan/infinispan/wiki/Clustered-listeners
[2] https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
Le 19. 11. 13 09:48, Emmanuel Bernard a écrit :
Hey there,
Here are a few comments based on a quick reading.
I might have totally misread or misinterpreted what was exposed, feel
free to correct me.
## General
I think you are restricting the design to listeners:
* that only listen to raw entry changes
* whose processing is remote
* with no way to filter out the event from the server
Is that correct? I can see that it does address the remote L1 use case
but I feel like it will close the doors to many more use cases. An
interesting example being continuous query.
In that use case the listener code runs a filtering logic server side
and only send keys that are impacted by the query plus some flag
defining whether it's added to changed or removed from the corpus.
The key is filtering event before sending it to the client.
I wish the design document was showing how we can achieve a general
purpose remote listener approach but have a step 1 that is only
targeting a restricted set of listeners if you feel that it's too much
to chew. I don't want us to be trapped in a situation where backward
compatibility prevent us from adding use cases.
## Specific questions
When the topology changes, it is the responsibility of the client to add
the listener to the new servers that show up. Correct? The API is a
global addRemoteListener but I imagine the client implementation will
have to transparently deal with that.
I wonder if a server approach is not more convinient. At least it does
not put the burden and bugs in several implementations and several
languages.
You never send code at the moment. Only one kind of listener is
available and listeners to all entry change and deletion. Correct?
Why not have the ability to listen to new entry events? That would limit
generic listeners as it is.
Do you have plans to make the ACK optional depending on the listener
requirement? Looks like an expensive process.
"Only the latest event is tracked for ACK for a given key"
It seems it's fine for L1 but would be a problem for many more generic
listeners.
Emmanuel
On Tue 2013-11-12 16:17, Galder Zamarreño 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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:07 a.m.
On Nov 19, 2013, at 1:17 PM, Pierre Sutra <pierre.sutra(a)unine.ch> wrote:
Dear Galder,
I have read with great interest the design document your wrote for Hot
Rod remote eventing [1].
I guess you mean [2] :)
In the perspective of the LEADS project, that aims at building a
continuous query/streaming engine on top of Infinispan, this new feature
seem very promising. However, it seems that in the current design their
is no mean to ensure dependability, i.e., the property that once
registered for a key k, a client will never miss an event regarding k,
even if the primary server in charge of k fails. How difficult do you
think it would be to ensure this ?
The initial design has focused on making sure the last available event is delivered to the
client, as opposed to all events for a particular key K. It seems like, as mentioned by
Emmanuel, to build a CQ engine, you'd need to receive all events for a particular key,
so we'll quite likely incorporate both options, depending on your use case.
Besides, following Emmanuel's opinion, I believe that it would be
useful
to notify a client on a new cache insertion and to allow it to set-up
filters on the servers (this last point is part of your clustered
listeners design document [2] but I do not know if you plan to
incorporate it to Hot-Rod).
Clustered listeners is a different topic since it's mostly focused around embedded
listeners, or listeners that run in the same VM as Infinispan.
In remote Hot Rod events we are focusing on cache events being fired back to Hot Rod
clients. There is certainly a lot of value in having server side filters defined which
control which events are fired back to Hot Rod clients. I do expect to incorporate this to
the design once this round of feedback has completed.
Side note on clustered listeners vs remote hot rod events:
There are some sinergies between remote Hot Rod events and clustere listeners, in that the
latter adds cluster wide state of listeners. Remote events might piggy back on this state
in order to maintain information about the remote listeners on the server side. This would
avoid the need for clients to register listeners when a new node joins.
Cheers,
Thank you in advance for your answers,
Best,
Pierre
[1] https://github.com/infinispan/infinispan/wiki/Clustered-listeners
[2] https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
Le 19. 11. 13 09:48, Emmanuel Bernard a écrit :
> Hey there,
>
> Here are a few comments based on a quick reading.
> I might have totally misread or misinterpreted what was exposed, feel
> free to correct me.
>
> ## General
>
> I think you are restricting the design to listeners:
>
> * that only listen to raw entry changes
> * whose processing is remote
> * with no way to filter out the event from the server
>
> Is that correct? I can see that it does address the remote L1 use case
> but I feel like it will close the doors to many more use cases. An
> interesting example being continuous query.
>
> In that use case the listener code runs a filtering logic server side
> and only send keys that are impacted by the query plus some flag
> defining whether it's added to changed or removed from the corpus.
> The key is filtering event before sending it to the client.
>
> I wish the design document was showing how we can achieve a general
> purpose remote listener approach but have a step 1 that is only
> targeting a restricted set of listeners if you feel that it's too much
> to chew. I don't want us to be trapped in a situation where backward
> compatibility prevent us from adding use cases.
>
> ## Specific questions
>
> When the topology changes, it is the responsibility of the client to add
> the listener to the new servers that show up. Correct? The API is a
> global addRemoteListener but I imagine the client implementation will
> have to transparently deal with that.
> I wonder if a server approach is not more convinient. At least it does
> not put the burden and bugs in several implementations and several
> languages.
>
> You never send code at the moment. Only one kind of listener is
> available and listeners to all entry change and deletion. Correct?
>
> Why not have the ability to listen to new entry events? That would limit
> generic listeners as it is.
>
> Do you have plans to make the ACK optional depending on the listener
> requirement? Looks like an expensive process.
>
> "Only the latest event is tracked for ACK for a given key"
> It seems it's fine for L1 but would be a problem for many more generic
> listeners.
>
> Emmanuel
>
>
> On Tue 2013-11-12 16:17, Galder Zamarreño 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
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
8:35 a.m.
Hi Emmanuel,
On Nov 19, 2013, at 9:48 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Hey there,
Here are a few comments based on a quick reading.
I might have totally misread or misinterpreted what was exposed, feel
free to correct me.
## General
I think you are restricting the design to listeners:
* that only listen to raw entry changes
* whose processing is remote
* with no way to filter out the event from the server
Is that correct? I can see that it does address the remote L1 use case
but I feel like it will close the doors to many more use cases. An
interesting example being continuous query.
Perfect. This is precisely the kind of feedback I was hoping to get :)
Indeed I had the remote L1 use case in mind, since that's probably one of the most
asked questions whenever I've presented about Infinispan Servers, but of course I
welcome other use cases, and I'm all in to make sure that the solution accomodates
other interesting use cases.
In that use case the listener code runs a filtering logic server
side
and only send keys that are impacted by the query plus some flag
defining whether it's added to changed or removed from the corpus.
The key is filtering event before sending it to the client.
I like this idea. It'd easier to manage this filtering on the server side than on the
client side, plus it would reduce traffic by making the filtering happen before it's
left the server. Assuming that filtering is done per-cache, the user would add a remote
listener for a cache, and the filtering of which keys to notify clients on would be
defined server side. The main capability you lose by doing this is the ability for
different clients to filter differently keys on the same cache, but I'm not sure how
common that'd be.
I wish the design document was showing how we can achieve a general
purpose remote listener approach but have a step 1 that is only
targeting a restricted set of listeners if you feel that it's too much
to chew. I don't want us to be trapped in a situation where backward
compatibility prevent us from adding use cases.
## Specific questions
When the topology changes, it is the responsibility of the client to add
the listener to the new servers that show up. Correct? The API is a
global addRemoteListener but I imagine the client implementation will
have to transparently deal with that.
I wonder if a server approach is not more convinient. At least it does
not put the burden and bugs in several implementations and several
languages.
I consider that but the thing is that clients already have to deal with cluster topology
changes. If a node joins or leaves, they already need to do some work to be able to
potentially redirect requests to the new node. I think registering listeners with newly
joining nodes would be a simple extension of that logic. IOW, after stablishing a
connection to the newly joined server, register listeners there. This avoids the need to
distribute state WRT listener registration, but as Radim pointed out in an earlier email,
there could be edge cases to cover if there's a delay in the registration of the
listener and some updates happen.
You never send code at the moment. Only one kind of listener is
available and listeners to all entry change and deletion. Correct?
Hmmm, not really. You shoud be able to add as many listeners as you want per cache.
Why not have the ability to listen to new entry events? That would
limit
generic listeners as it is.
This could be part of the filtering logic somehow. I mean, there's two types of
filtering:
1. Filtering by type of operation: create, update, remove
2. Filter by key
Filtering by key can possibly done on the server side as you suggest. What about filtering
by type of operation? Doing it server side again would hugely reduce traffic.
Do you have plans to make the ACK optional depending on the listener
requirement? Looks like an expensive process.
It could be optional indeed.
"Only the latest event is tracked for ACK for a given key"
It seems it's fine for L1 but would be a problem for many more generic
listeners.
Again, we could make it optional to either track ACKs for latest event, or track ACKs for
all events, but putting a limit somewhere.
Once again, thanks for the excellent feedback.
Cheers,
Emmanuel
On Tue 2013-11-12 16:17, Galder Zamarreño 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
_______________________________________________
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
2:01 p.m.
Cool, I was afraid you had sent my feedback to /dev/null :)
On Wed 2013-11-27 8:35, Galder Zamarreño wrote:
> In that use case the listener code runs a filtering logic server
side
> and only send keys that are impacted by the query plus some flag
> defining whether it's added to changed or removed from the corpus.
> The key is filtering event before sending it to the client.
I like this idea. It'd easier to manage this filtering on the server side than on the
client side, plus it would reduce traffic by making the filtering happen before it's
left the server. Assuming that filtering is done per-cache, the user would add a remote
listener for a cache, and the filtering of which keys to notify clients on would be
defined server side. The main capability you lose by doing this is the ability for
different clients to filter differently keys on the same cache, but I'm not sure how
common that'd be.
Actually, a client could "manually" do client side filtering if it
pleases him or if it makes more sense. From the server PoV you would
simply return all events to that client because the client would have
activated the "all your base are belong to us" listener.
> You never send code at the moment. Only one kind of listener is
> available and listeners to all entry change and deletion. Correct?
Hmmm, not really. You shoud be able to add as many listeners as you want per cache.
Yes but in your approach there are client side listeners so the listener code is
not shipped to the server.
In a subsequent discussion on this thread, I proposed the idea of named
listeners whose code is already pre deployed on the server.
Plus we can imagine using the scripting integration engine in the JVM to
run code that does not require a compilation phase.
> Why not have the ability to listen to new entry events? That
would limit
> generic listeners as it is.
This could be part of the filtering logic somehow. I mean, there's two types of
filtering:
1. Filtering by type of operation: create, update, remove
2. Filter by key
Filtering by key can possibly done on the server side as you suggest. What about
filtering by type of operation? Doing it server side again would hugely reduce traffic.
To me all can be done on the server. And as I said earlier, we could
have a default listener that listens to everything and send all events
to the client. In that case the client is responsible for discarding
events as it pleases. Basically your use case will be covered by the
server side approach AFAIU.
Anyways back to the 3000 meters view, if you go for the server side
approach, I think we will ahve a much more powerful and efficient
solution esp since we can emulate the client side approach with it.
Emmanuel
3:17 p.m.
On Nov 27, 2013, at 7:35 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
Hi Emmanuel,
On Nov 19, 2013, at 9:48 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> Hey there,
>
> Here are a few comments based on a quick reading.
> I might have totally misread or misinterpreted what was exposed, feel
> free to correct me.
>
> ## General
>
> I think you are restricting the design to listeners:
>
> * that only listen to raw entry changes
> * whose processing is remote
> * with no way to filter out the event from the server
>
> Is that correct? I can see that it does address the remote L1 use case
> but I feel like it will close the doors to many more use cases. An
> interesting example being continuous query.
Perfect. This is precisely the kind of feedback I was hoping to get :)
Indeed I had the remote L1 use case in mind, since that's probably one of the most
asked questions whenever I've presented about Infinispan Servers, but of course I
welcome other use cases, and I'm all in to make sure that the solution accomodates
other interesting use cases.
> In that use case the listener code runs a filtering logic server side
> and only send keys that are impacted by the query plus some flag
> defining whether it's added to changed or removed from the corpus.
> The key is filtering event before sending it to the client.
I like this idea. It'd easier to manage this filtering on the server side than on the
client side, plus it would reduce traffic by making the filtering happen before it's
left the server. Assuming that filtering is done per-cache, the user would add a remote
listener for a cache, and the filtering of which keys to notify clients on would be
defined server side. The main capability you lose by doing this is the ability for
different clients to filter differently keys on the same cache, but I'm not sure how
common that'd be.
I think the filters should be on a per cache basis. This would require us to be able
describe the filter code in a language neutral manner, a bit out of scope for this
iteration, but very nice idea IMO.
> I wish the design document was showing how we can achieve a general
> purpose remote listener approach but have a step 1 that is only
> targeting a restricted set of listeners if you feel that it's too much
> to chew. I don't want us to be trapped in a situation where backward
> compatibility prevent us from adding use cases.
>
> ## Specific questions
>
> When the topology changes, it is the responsibility of the client to add
> the listener to the new servers that show up. Correct? The API is a
> global addRemoteListener but I imagine the client implementation will
> have to transparently deal with that.
> I wonder if a server approach is not more convinient. At least it does
> not put the burden and bugs in several implementations and several
> languages.
I consider that but the thing is that clients already have to deal with cluster topology
changes. If a node joins or leaves, they already need to do some work to be able to
potentially redirect requests to the new node. I think registering listeners with newly
joining nodes would be a simple extension of that logic. IOW, after stablishing a
connection to the newly joined server, register listeners there. This avoids the need to
distribute state WRT listener registration, but as Radim pointed out in an earlier email,
there could be edge cases to cover if there's a delay in the registration of the
listener and some updates happen.
> You never send code at the moment. Only one kind of listener is
> available and listeners to all entry change and deletion. Correct?
Hmmm, not really. You shoud be able to add as many listeners as you want per cache.
> Why not have the ability to listen to new entry events? That would limit
> generic listeners as it is.
This could be part of the filtering logic somehow. I mean, there's two types of
filtering:
1. Filtering by type of operation: create, update, remove
2. Filter by key
Filtering by key can possibly done on the server side as you suggest. What about
filtering by type of operation? Doing it server side again would hugely reduce traffic.
> Do you have plans to make the ACK optional depending on the listener
> requirement? Looks like an expensive process.
It could be optional indeed.
> "Only the latest event is tracked for ACK for a given key"
> It seems it's fine for L1 but would be a problem for many more generic
> listeners.
Again, we could make it optional to either track ACKs for latest event, or track ACKs for
all events, but putting a limit somewhere.
Once again, thanks for the excellent feedback.
Cheers,
>
> Emmanuel
>
>
> On Tue 2013-11-12 16:17, Galder Zamarreño 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
> _______________________________________________
> 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)
3819
days inactive
3839
days old
infinispan-dev@lists.jboss.org
20 comments
6 participants
participants (6)
-
Dan Berindei -
Emmanuel Bernard -
Galder Zamarreño -
Mircea Markus -
Pierre Sutra -
Radim Vansa