On Dec 19, 2013, at 1:15 PM, Emmanuel Bernard emman...@hibernate.org wrote:
On Thu 2013-12-19 9:46, Galder Zamarreño wrote:
== Example of continuous query atop remote listeners
Thinking about how to implement continuous query atop this
infrastructure I am missing a few things.
The
On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard emman...@hibernate.orgwrote:
On Thu 2013-12-19 19:57, Dan Berindei wrote:
On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard
emman...@hibernate.orgwrote:
On Thu 2013-12-19 9:46, Galder Zamarreño wrote:
== Example of continuous query
On Fri, Dec 13, 2013 at 4:11 PM, Radim Vansa rva...@redhat.com wrote:
On 12/13/2013 02:44 PM, Galder Zamarreño wrote:
On Dec 6, 2013, at 10:45 AM, Radim Vansa rva...@redhat.com wrote:
Hi,
1) IMO, filtering for specific key is a very important use case.
Registering a filterId is a very
On Fri, Dec 20, 2013 at 12:20 PM, Emmanuel Bernard
emman...@hibernate.orgwrote:
On Fri 2013-12-20 12:09, Dan Berindei wrote:
On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard
emman...@hibernate.orgwrote:
On Thu 2013-12-19 19:57, Dan Berindei wrote:
On Thu, Dec 19, 2013 at 2:15 PM,
On Dec 13, 2013, at 4:33 PM, Radim Vansa rva...@redhat.com wrote:
On 12/13/2013 03:49 PM, Galder Zamarreño wrote:
On Dec 6, 2013, at 4:17 PM, Radim Vansa rva...@redhat.com wrote:
Btw., when Hot Rod fails to hit the primary owner, should the non-owner
propagate the SourceID to primary
On Dec 13, 2013, at 5:08 PM, Emmanuel Bernard emman...@hibernate.org wrote:
Much better. Some more feedback.
== Filter and converter
I am wondering if there is a benefit in separating filters and
converters. It does add some understanding complexity so a single
ServerListener with the
On Thu 2013-12-19 9:46, Galder Zamarreño wrote:
== Example of continuous query atop remote listeners
Thinking about how to implement continuous query atop this
infrastructure I am missing a few things.
The primary problem is that I don't want to enlist a filter id per
continuous
Hi Galder,
regarding the Client Identification paragraph I was thinking of the
connection there might be with authenticated session ids I describe in
the security document [1] in order to reduce the potential proliferation
of identifiers.
In the security case it is the server who is
On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard emman...@hibernate.orgwrote:
On Thu 2013-12-19 9:46, Galder Zamarreño wrote:
== Example of continuous query atop remote listeners
Thinking about how to implement continuous query atop this
infrastructure I am missing a few things.
On Thu 2013-12-19 19:57, Dan Berindei wrote:
On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard
emman...@hibernate.orgwrote:
On Thu 2013-12-19 9:46, Galder Zamarreño wrote:
== Example of continuous query atop remote listeners
Thinking about how to implement continuous query atop
On Dec 13, 2013, at 3:11 PM, Radim Vansa rva...@redhat.com wrote:
On 12/13/2013 02:44 PM, Galder Zamarreño wrote:
On Dec 6, 2013, at 10:45 AM, Radim Vansa rva...@redhat.com wrote:
Hi,
1) IMO, filtering for specific key is a very important use case.
Registering a filterId is a very
On Dec 6, 2013, at 10:45 AM, Radim Vansa rva...@redhat.com wrote:
Hi,
1) IMO, filtering for specific key is a very important use case. Registering
a filterId is a very powerful feature, but as long as you don't provide
runtime parameter for this filter, you cannot implement one-key
On 12/13/2013 02:44 PM, Galder Zamarreño wrote:
On Dec 6, 2013, at 10:45 AM, Radim Vansa rva...@redhat.com wrote:
Hi,
1) IMO, filtering for specific key is a very important use case. Registering
a filterId is a very powerful feature, but as long as you don't provide
runtime parameter for
On Dec 6, 2013, at 3:52 PM, Mircea Markus mmar...@redhat.com wrote:
Some notes:
This means that the Hot Rod protocol will be extended so that operation
headers always carry a Source ID field.
- shall we add a new intelligence level to handle this? Besides reducing the
payload, would
On Dec 9, 2013, at 6:47 PM, Mircea Markus mmar...@redhat.com wrote:
Hey Galder,
Another idea that come up today was to use the QueryDSL for specifying both
the filter and the transformer (the DSL has projection).
The query DSL builds an HQL string for which one the server side the filter
On 12/13/2013 03:49 PM, Galder Zamarreño wrote:
On Dec 6, 2013, at 4:17 PM, Radim Vansa rva...@redhat.com wrote:
Btw., when Hot Rod fails to hit the primary owner, should the non-owner
propagate the SourceID to primary owner somehow? Or is in this case
acceptable notifying the listener
Much better. Some more feedback.
== Filter and converter
I am wondering if there is a benefit in separating filters and
converters. It does add some understanding complexity so a single
ServerListener with the methods from RemoteFilter / RemoveConverter
might be better.
Should filter /
Hey Galder,
Another idea that come up today was to use the QueryDSL for specifying both the
filter and the transformer (the DSL has projection).
The query DSL builds an HQL string for which one the server side the filter can
be built on the fly (we already do that with the embedded query DSL).
Hi,
1) IMO, filtering for specific key is a very important use case.
Registering a filterId is a very powerful feature, but as long as you
don't provide runtime parameter for this filter, you cannot implement
one-key filtering.
2) setting ack/no ack in listener, and then configuring
Some notes:
This means that the Hot Rod protocol will be extended so that operation
headers always carry a Source ID field.
- shall we add a new intelligence level to handle this? Besides reducing the
payload, would allow upgrading the java and Cpp clients independently.
In one of our
On 12/06/2013 03:52 PM, Mircea Markus wrote:
Some notes:
This means that the Hot Rod protocol will be extended so that operation
headers always carry a Source ID field.
- shall we add a new intelligence level to handle this? Besides reducing the
payload, would allow upgrading the java and
On 12/06/2013 08:52 AM, Mircea Markus wrote:
Some notes:
This means that the Hot Rod protocol will be extended so that operation
headers always carry a Source ID field.
- shall we add a new intelligence level to handle this? Besides reducing the
payload, would allow upgrading the java and
Hi all,
Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
Thanks a lot for the feedback provided in last thread. It was very constructive
feedback :)
I've just finished updating the design document with the feedback provided in
the previous email thread. Can you please
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.
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 rva...@redhat.com wrote:
Hi, my couple of questions remarks:
1. Why there is no RemoteCacheEntryCreated? I guess you had good reason
to
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
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
On Dec 2, 2013, at 10:57 AM, Radim Vansa rva...@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 rva...@redhat.com wrote:
3. IMO, registering events for particular
Hi Emmanuel,
On Nov 19, 2013, at 9:48 AM, Emmanuel Bernard emman...@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
On Nov 19, 2013, at 12:23 PM, Radim Vansa rva...@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
On Nov 19, 2013, at 1:17 PM, Pierre Sutra pierre.su...@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
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
On Nov 26, 2013, at 3:49 PM, Galder Zamarreño gal...@redhat.com wrote:
On Nov 19, 2013, at 2:49 AM, Mircea Markus mmar...@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:
On Nov 27, 2013, at 7:35 AM, Galder Zamarreño gal...@redhat.com wrote:
Hi Emmanuel,
On Nov 19, 2013, at 9:48 AM, Emmanuel Bernard emman...@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,
On Nov 19, 2013, at 2:49 AM, Mircea Markus mmar...@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
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
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
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
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
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
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
41 matches
Mail list logo
