From galder at redhat.com  Mon Dec  2 04:44:00 2013
From: galder at redhat.com (=?windows-1252?Q?Galder_Zamarre=F1o?=)
Date: Mon, 2 Dec 2013 10:44:00 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events
In-Reply-To: <ED03D8EE-C58C-4BF0-A41B-1CE48C1B5659@redhat.com>
References: <17E61B53-0C1A-4D80-B841-EA15EBD772BF@redhat.com>
	<B24B97D0-1AA0-4970-BB6A-ADB267921298@redhat.com>
	<3DF5764B-96E8-4CAD-A5C7-95E8BAFD9CFB@redhat.com>
	<ED03D8EE-C58C-4BF0-A41B-1CE48C1B5659@redhat.com>
Message-ID: <6805B558-0CB6-4E38-81B7-A897E217750C@redhat.com>


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?

> 
>> 
>> 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



From rvansa at redhat.com  Mon Dec  2 04:57:46 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 02 Dec 2013 10:57:46 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events
In-Reply-To: <E6020E4C-DE09-4A1B-BBBE-C6390B89F0A5@redhat.com>
References: <17E61B53-0C1A-4D80-B841-EA15EBD772BF@redhat.com>
	<52835574.6080806@redhat.com>
	<E6020E4C-DE09-4A1B-BBBE-C6390B89F0A5@redhat.com>
Message-ID: <529C599A.2030605@redhat.com>

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 at 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 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
>>
>> -- 
>> Radim Vansa <rvansa at redhat.com>
>> JBoss DataGrid QA
>>
>> _______________________________________________
>> 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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA


From dan.berindei at gmail.com  Mon Dec  2 05:00:55 2013
From: dan.berindei at gmail.com (Dan Berindei)
Date: Mon, 2 Dec 2013 12:00:55 +0200
Subject: [infinispan-dev] Design of Remote Hot Rod events
In-Reply-To: <6805B558-0CB6-4E38-81B7-A897E217750C@redhat.com>
References: <17E61B53-0C1A-4D80-B841-EA15EBD772BF@redhat.com>
	<B24B97D0-1AA0-4970-BB6A-ADB267921298@redhat.com>
	<3DF5764B-96E8-4CAD-A5C7-95E8BAFD9CFB@redhat.com>
	<ED03D8EE-C58C-4BF0-A41B-1CE48C1B5659@redhat.com>
	<6805B558-0CB6-4E38-81B7-A897E217750C@redhat.com>
Message-ID: <CA+nfvwTy1nqe7O8wJVynT0NLZ+pFtwN6DPhM9MRqSa-Fe4Qxgw@mail.gmail.com>

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 

From mmarkus at redhat.com  Mon Dec  2 06:44:45 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Mon, 2 Dec 2013 11:44:45 +0000
Subject: [infinispan-dev] Design of Remote Hot Rod events
In-Reply-To: <CA+nfvwTy1nqe7O8wJVynT0NLZ+pFtwN6DPhM9MRqSa-Fe4Qxgw@mail.gmail.com>
References: <17E61B53-0C1A-4D80-B841-EA15EBD772BF@redhat.com>
	<B24B97D0-1AA0-4970-BB6A-ADB267921298@redhat.com>
	<3DF5764B-96E8-4CAD-A5C7-95E8BAFD9CFB@redhat.com>
	<ED03D8EE-C58C-4BF0-A41B-1CE48C1B5659@redhat.com>
	<6805B558-0CB6-4E38-81B7-A897E217750C@redhat.com>
	<CA+nfvwTy1nqe7O8wJVynT0NLZ+pFtwN6DPhM9MRqSa-Fe4Qxgw@mail.gmail.com>
Message-ID: <A1F733B5-29A7-4477-A9F5-5ECF50A57302@redhat.com>


On Dec 2, 2013, at 10:00 AM, Dan Berindei <dan.berindei at gmail.com> wrote:

> 
> 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?

+1. It is a bit large but I think it would do in the first iteration.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)






From galder at redhat.com  Mon Dec  2 10:44:22 2013
From: galder at redhat.com (=?windows-1252?Q?Galder_Zamarre=F1o?=)
Date: Mon, 2 Dec 2013 16:44:22 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events
In-Reply-To: <529C599A.2030605@redhat.com>
References: <17E61B53-0C1A-4D80-B841-EA15EBD772BF@redhat.com>
	<52835574.6080806@redhat.com>
	<E6020E4C-DE09-4A1B-BBBE-C6390B89F0A5@redhat.com>
	<529C599A.2030605@redhat.com>
Message-ID: <2D449F66-D505-4FB4-BCC2-D3CD9985540C@redhat.com>


On Dec 2, 2013, at 10:57 AM, Radim Vansa <rvansa at 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 at 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 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
>>> 
>>> -- 
>>> Radim Vansa <rvansa at redhat.com>
>>> JBoss DataGrid QA
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
> 
> _______________________________________________
> 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



From mmarkus at redhat.com  Mon Dec  2 21:07:20 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Tue, 3 Dec 2013 02:07:20 +0000
Subject: [infinispan-dev] CI run for the Cpp client
In-Reply-To: <529C4C56.7090204@redhat.com>
References: <B9560FBB-F9A7-43D2-93DF-5A0467800ED1@redhat.com>
	<529C4C56.7090204@redhat.com>
Message-ID: <7436F25C-A7CC-4687-A330-C58B66DDCBA7@redhat.com>

Thanks, Ion!
On Dec 2, 2013, at 9:01 AM, isavin at redhat.com wrote:

> On 11/19/2013 11:27 PM, Mircea Markus wrote:
>> Hi,
>> 
>> Ion has access to my AWS account so he can launch new instances.
>> 
>> From the top of my head, for the Cpp client CI we'd need:
>> - an RHEL5 build on every check in
>> - an RHEL6 build on every check in
>> - an Windows 7 (?) build on every check in
>> Same for pull every pull requests.
>> 
>> Work to integration with the teamcity is also need. (Ion you should have credentials for connecting to ci.infinispan.org.)
>> 
>> For cost reasons, these instances should only be launched when there's activity.
>> Please also give a cost estimate (monthly + initial) so that we can get an idea of the budget needed.
>> 
>> Cheers,
> 
> Hi Mircea,
> 
> Here are some cost estimates:
> 
> RHEL5:
> * m1.small RHEL 5.9 x86_64 (initial: $0; per hour: $0.12; ~$30 per month with 8h/day usage)
> 
> RHEL6:
> * m1.small RHEL 6.4 x86_64 (initial: $0; per hour: $0.12; ~$30 per month with 8h/day usage)
> 
> Windows Build Configuration (could use this for HotRod C# also):
> * m1.small with Windows Server 2012 x86_64 (initial: $0; per hour $0.091; ~$23 per month with 8h/day usage)
> * Visual Studio 2013 perpetual license (without MSDN subscription): (initial: ~$1000 after: $0)

What about running just the .NET tests (when available) on the windows machine? I assume we won't need a full VS2013 license for that, but just the .NET framework which is free (?)

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)






From mmarkus at redhat.com  Mon Dec  2 22:10:39 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Tue, 3 Dec 2013 03:10:39 +0000
Subject: [infinispan-dev] Integration between HotRod and OGM
In-Reply-To: <20131119102205.GL3262@hibernate.org>
References: <CANoTJYPHTFoKCnvFmv8vd9dkonq2XJ22MXQN6Hi6Zv7D=Edspw@mail.gmail.com>
	<20131112145454.GB5423@hibernate.org>
	<CAFm4XO06Sr5pC+wLach1szbFkGVCp0etyFJ3YEufZwAY4A3C9Q@mail.gmail.com>
	<20131118095612.GN3262@hibernate.org>
	<24C30EDB-1978-4AB0-93F8-A02B35C1193C@redhat.com>
	<20131119102205.GL3262@hibernate.org>
Message-ID: <0F4A687C-0A39-4748-A9BA-942A850457E7@redhat.com>


On Nov 19, 2013, at 10:22 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> It's an interesting approach that would work fine-ish for entities
> assuming the Hot Rod client is multi threaded and assuming the client
> uses Future to parallelize the calls.

The Java Hotrod client is both multithreaded and exposes an Async API.

> 
> But it won't work for associations as we have them designed today.
> Each association - or more precisely the query results to go from an
> entity A1 to the list of entities B associated to it - is represented by
> an AtomicMap.
> Each entry in this map does correspond to an entry in the association.
> 
> While we can "guess" the column names and build from the metadata the
> list of composed keys for entities, we cannot do the same for
> associations as the key is literally the (composite) id of the
> association and we cannot guess that most of the time (we can in very
> pathological cases).
> We could imagine that we list the association row keys in a special
> entry to work around that but this approach is just as problematic and
> is conceptually the same.
> The only solution would be to lock the whole association for each
> operation and I guess impose some versioning / optimistic lock.
> 
> That is not a pattern that scales sufficiently from my experience.

I think so too :-)

> That's the problem with interconnected data :)
> 
> Emmanuel
> 
> On Mon 2013-11-18 23:05, Mircea Markus wrote:
>> Neither the grouping API nor the AtomicMap work over hotrod.
>> Between the grouping API and AtomicMap, I think the one that would make more sense migrating is the grouping API.
>> One way or the other, I think the hotrod protocol would require an enhancement - mind raising a JIRA for that?
>> For now I guess you can sacrifice performance and always sending the entire object across on every update instead of only the deltas?
>> 
>> On Nov 18, 2013, at 9:56 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>>> Someone mentioned the grouping API as some sort of alternative to
>>> AtomicMap. Maybe we should use that?
>>> Note that if we don't have a fine-grained approach we will need to
>>> make sure we *copy* the complex data structure upon reads to mimic
>>> proper transaction isolation.
>>> 
>>> On Tue 2013-11-12 15:14, Sanne Grinovero wrote:
>>>> On 12 November 2013 14:54, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>>> On the transaction side, we can start without them.
>>>> 
>>>> +1 on omitting transactions for now.
>>>> 
>>>> And on the missing AtomicMaps, I hope the Infinispan will want to implement it?
>>>> Would be good to eventually converge on similar featuresets on remote
>>>> vs embedded APIs.
>>>> 
>>>> I know the embedded version relies on batching/transactions, but I
>>>> guess we could obtain a similar effect with some ad-hoc commands in
>>>> Hot Rod?
>>>> 
>>>> Sanne
>>>> 
>>>>> 
>>>>> On Tue 2013-11-12 14:34, Davide D'Alto wrote:
>>>>>> Hi,
>>>>>> I'm working on the integration between HotRod and OGM.
>>>>>> 
>>>>>> We already have a dialect for Inifinispan and I'm trying to follow the same
>>>>>> logic.
>>>>>> At the moment I'm having two problems:
>>>>>> 
>>>>>> 1) In the Infinispan dialect we are using the AtomicMap and the
>>>>>> AtomicMapLookup but this classes don't work with the RemoteCache. Is there
>>>>>> an equivalent for HotRod?
>>>>>> 
>>>>>> 2) As far as I know HotRod does not support transactions. I've found a link
>>>>>> to a branch on Mircea repository:
>>>>>> https://github.com/mmarkus/ops_over_hotrod/wiki/Usage-guide
>>>>>> Is this something I could/should use?
>>>>>> 
>>>>>> Any help is appreciated.
>>>>>> 
>>>>>> Thanks,
>>>>>> Davide
>>>>> 
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> 
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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)






From isavin at redhat.com  Tue Dec  3 02:27:17 2013
From: isavin at redhat.com (isavin at redhat.com)
Date: Tue, 03 Dec 2013 09:27:17 +0200
Subject: [infinispan-dev] CI run for the Cpp client
In-Reply-To: <7436F25C-A7CC-4687-A330-C58B66DDCBA7@redhat.com>
References: <B9560FBB-F9A7-43D2-93DF-5A0467800ED1@redhat.com>
	<529C4C56.7090204@redhat.com>
	<7436F25C-A7CC-4687-A330-C58B66DDCBA7@redhat.com>
Message-ID: <529D87D5.8020705@redhat.com>

>> Windows Build Configuration (could use this for HotRod C# also):
>> * m1.small with Windows Server 2012 x86_64 (initial: $0; per hour $0.091; ~$23 per month with 8h/day usage)
>> * Visual Studio 2013 perpetual license (without MSDN subscription): (initial: ~$1000 after: $0)
>
> What about running just the .NET tests (when available) on the windows machine? I assume we won't need a full VS2013 license for that, but just the .NET framework which is free (?)

For .NET it should work without VS.

Regards,
  Ion Savin


From mlittle at redhat.com  Tue Dec  3 08:26:09 2013
From: mlittle at redhat.com (Mark Little)
Date: Tue, 3 Dec 2013 13:26:09 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <E9EB86AE-C238-4985-892F-4F5CED6A731D@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<1384267860.18422.126.camel@T520>
	<F8A0D59A-7E36-4CCE-95EF-696709F8EC82@redhat.com>
	<528B1766.5010909@redhat.com>
	<8E6ED5F3-9747-411D-B212-5AB9FB5CAA61@redhat.com>
	<BAY174-DS18E1CB6D3AA4753056F848C3E70@phx.gbl>
	<CA+nfvwTZBR-D701hdSyFr5yLfJEmvNu53wLpFk8tH5pR06o68Q@mail.gmail.com>
	<553828B2-4F7E-45E8-8445-CFAFBDF89E33@redhat.com>
	<CA+nfvwRWjPsm5jr7LkeeJgOyN+sk0AYXGpzYzakvNg-OKFoUPg@mail.gmail.com>
	<408CD088-1940-400C-BD09-FDF63BDF6698@redhat.com>
	<528C8BD8.9010208@infinispan.org>
	<7262CC7E-316D-47DB-B0F3-37399B30D172@redhat.com>
	<528DF53C.8030602@infinispan.org>
	<CA+nfvwQG=t7pLfcCgCqLCAws1S0thDS_zo=OHSuq_=_EC=YUyA@mail.gmail.com>
	<E9EB86AE-C238-4985-892F-4F5CED6A731D@redhat.com>
Message-ID: <181E3433-D991-46E0-822F-EAAEB2BB36C6@redhat.com>

Why write a log if there is no recovery? That's wrong.

Mark.


On 29 Nov 2013, at 14:39, Mircea Markus wrote:

> 
> On Nov 21, 2013, at 3:18 PM, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
>> Hmm, couldn't you just disable recovery in the TM to get the same performance with a XA resource as with a synchronization?
>> 
> 
> I don't think that would be enough actually. Even without recovery, for transactions (XA) that have more than one participant registered, the TM writes information on the transaction log.
> This is a persistent log and writing to it slows down things.
> 
> 
>> 
>> On Thu, Nov 21, 2013 at 1:57 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
>> 
>> 
>> On 11/21/2013 11:34 AM, Galder Zamarre?o wrote:
>>> 
>>> 
>>> It's way faster actually. The speed difference from all the extra work required by Transaction Manager to deal with multiple XA resources, make transactions recoverable..etc. We've done tests in the past (i.e. Hibernate 2LC) comparing both and the difference was quite big.
>>> 
>> 
>> you are right. I forgot the recovery mechanism :)
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> _______________________________________________
>> 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

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).






From mlittle at redhat.com  Tue Dec  3 08:28:53 2013
From: mlittle at redhat.com (Mark Little)
Date: Tue, 3 Dec 2013 13:28:53 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <3D287693-E1F4-4C8F-8605-67084C7BDD15@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<AF2F210C-1890-41A5-B19F-3E4CA8FDA669@redhat.com>
	<3D287693-E1F4-4C8F-8605-67084C7BDD15@redhat.com>
Message-ID: <B7AD62F5-5F71-4C4C-A5DA-EDDB1F24D9B1@redhat.com>


On 29 Nov 2013, at 15:54, Mircea Markus wrote:

> 
> On Nov 29, 2013, at 1:45 PM, Mark Little <mlittle at redhat.com> wrote:
> 
>> I haven't looked at how ISPN does this today, but here are some thoughts given how we do this within the transaction system for ACID transactions:
>> 
>> (i) have you considered async prepare?
> 
> There is a certain degree of asynchronicity in the sense that the prepare we send happens in parallel on all the nodes involved in the transaction. Is this what you have in mind? 

With async prepare you send each prepare request asynchronously (!) and then wait for responses, rather than send each prepare and wait for a response before moving on to the next prepare request.

> 
>> 
>> (ii) async commit/rollback could involve an external audit component to capture the outcome of the transaction, which can be inspected later. Many years ago the OTS and CORBA Notification Service did this together.
> 
> If the commit/rollback fails this should be picked up by the TM recovery process - I guess that would do the job. 
> This improves the throughput indeed, but might be confusing for users: reading the data written by a "successfully" completed transaction (i.e. TM.commit() returns without exception) would not work.

Data cannot be read until the transaction has completed (one way or another). So I'm not sure what the problem is you're alluding to here.

Mark.


> 
>> 
>> (iii) if you don't allow heuristics then there are guarantees with async commit/rollback.
>> 
>> Mark.
>> 
>> 
>> On 8 Nov 2013, at 15:28, Mircea Markus wrote:
>> 
>>> 1. Async options for commit/rollback
>>> - they don't really make sense as a user you don't get any guarantee on the status of the transaction
>>> - they complicate the code significantly
>>> - I think they should be removed
>> 
>> ---
>> Mark Little
>> mlittle at redhat.com
>> 
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).






From mlittle at redhat.com  Tue Dec  3 08:29:42 2013
From: mlittle at redhat.com (Mark Little)
Date: Tue, 3 Dec 2013 13:29:42 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <8D372EA7-53BE-481A-91A8-9AEBFA217C0A@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<686D0C9A-9DCA-44AE-B6C3-C4BB1B6A3D13@redhat.com>
	<8D372EA7-53BE-481A-91A8-9AEBFA217C0A@redhat.com>
Message-ID: <9E30661C-7036-4A42-A37A-208B8B24F2C5@redhat.com>

Oh please tell me your 1PC isn't really 2PC on multiple participants but without a prepare phase?!

Mark.


On 29 Nov 2013, at 15:59, Mircea Markus wrote:

> On Nov 29, 2013, at 1:46 PM, Mark Little <mlittle at redhat.com> wrote:
> 
>> Why do you think there are no consistency guarantees? Again this may be a difference in the way you use the term 1PC versus how it's used and implemented elsewhere.
> 
> Indedd, 1PC here has to do with the consensus protocol used by Infinispan internally to update the same data on multiple nodes. Doesn't have to do with the XAResource.commit(xid, isOnePhase) at all (we actually plan to implement that 1PC optimization in the case a single node needs to be updated). 
> 
>> 
>> Mark.
>> 
>> 
>> On 8 Nov 2013, at 15:28, Mircea Markus wrote:
>> 
>>> 4. Remove 1PC option
>>> - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing
>> 
> 
> 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

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).






From mmarkus at redhat.com  Tue Dec  3 08:51:22 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Tue, 3 Dec 2013 13:51:22 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <181E3433-D991-46E0-822F-EAAEB2BB36C6@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<1384267860.18422.126.camel@T520>
	<F8A0D59A-7E36-4CCE-95EF-696709F8EC82@redhat.com>
	<528B1766.5010909@redhat.com>
	<8E6ED5F3-9747-411D-B212-5AB9FB5CAA61@redhat.com>
	<BAY174-DS18E1CB6D3AA4753056F848C3E70@phx.gbl>
	<CA+nfvwTZBR-D701hdSyFr5yLfJEmvNu53wLpFk8tH5pR06o68Q@mail.gmail.com>
	<553828B2-4F7E-45E8-8445-CFAFBDF89E33@redhat.com>
	<CA+nfvwRWjPsm5jr7LkeeJgOyN+sk0AYXGpzYzakvNg-OKFoUPg@mail.gmail.com>
	<408CD088-1940-400C-BD09-FDF63BDF6698@redhat.com>
	<528C8BD8.9010208@infinispan.org>
	<7262CC7E-316D-47DB-B0F3-37399B30D172@redhat.com>
	<528DF53C.8030602@infinispan.org>
	<CA+nfvwQG=t7pLfcCgCqLCAws1S0thDS_zo=OHSuq_=_EC=YUyA@mail.gmail.com>
	<E9EB86AE-C238-4985-892F-4F5CED6A731D@redhat.com>
	<181E3433-D991-46E0-822F-EAAEB2BB36C6@redhat.com>
Message-ID: <832F2890-B944-479D-A7B0-C247B79814AF@redhat.com>

On Dec 3, 2013, at 1:26 PM, Mark Little <mlittle at redhat.com> wrote:

> Why write a log if there is no recovery? That's wrong.

AFAIK the recovery is configured as a separate subsystem within the TM. If recovery can be disabled entirely within TM, including TM's log writes, then indeed as Dan suggested, XA resource enlisted would have the same performance as synchronization enlistments. I don't find this setup very nice though :-)

> 
> Mark.
> 
> 
> On 29 Nov 2013, at 14:39, Mircea Markus wrote:
> 
>> 
>> On Nov 21, 2013, at 3:18 PM, Dan Berindei <dan.berindei at gmail.com> wrote:
>> 
>>> Hmm, couldn't you just disable recovery in the TM to get the same performance with a XA resource as with a synchronization?
>>> 
>> 
>> I don't think that would be enough actually. Even without recovery, for transactions (XA) that have more than one participant registered, the TM writes information on the transaction log.
>> This is a persistent log and writing to it slows down things.
>> 
>> 
>>> 
>>> On Thu, Nov 21, 2013 at 1:57 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
>>> 
>>> 
>>> On 11/21/2013 11:34 AM, Galder Zamarre?o wrote:
>>>> 
>>>> 
>>>> It's way faster actually. The speed difference from all the extra work required by Transaction Manager to deal with multiple XA resources, make transactions recoverable..etc. We've done tests in the past (i.e. Hibernate 2LC) comparing both and the difference was quite big.
>>>> 
>>> 
>>> you are right. I forgot the recovery mechanism :)
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>>> _______________________________________________
>>> 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
> 
> ---
> Mark Little
> mlittle at redhat.com
> 
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
> 
> 
> 
> 
> 
> _______________________________________________
> 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)






From mmarkus at redhat.com  Tue Dec  3 08:58:55 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Tue, 3 Dec 2013 13:58:55 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <B7AD62F5-5F71-4C4C-A5DA-EDDB1F24D9B1@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<AF2F210C-1890-41A5-B19F-3E4CA8FDA669@redhat.com>
	<3D287693-E1F4-4C8F-8605-67084C7BDD15@redhat.com>
	<B7AD62F5-5F71-4C4C-A5DA-EDDB1F24D9B1@redhat.com>
Message-ID: <90F8EBE7-B29C-4008-9A39-BFD73CB55248@redhat.com>


On Dec 3, 2013, at 1:28 PM, Mark Little <mlittle at redhat.com> wrote:

> 
> On 29 Nov 2013, at 15:54, Mircea Markus wrote:
> 
>> 
>> On Nov 29, 2013, at 1:45 PM, Mark Little <mlittle at redhat.com> wrote:
>> 
>>> I haven't looked at how ISPN does this today, but here are some thoughts given how we do this within the transaction system for ACID transactions:
>>> 
>>> (i) have you considered async prepare?
>> 
>> There is a certain degree of asynchronicity in the sense that the prepare we send happens in parallel on all the nodes involved in the transaction. Is this what you have in mind? 
> 
> With async prepare you send each prepare request asynchronously (!) and then wait for responses, rather than send each prepare and wait for a response before moving on to the next prepare request.

That is exactly what we do.

> 
>> 
>>> 
>>> (ii) async commit/rollback could involve an external audit component to capture the outcome of the transaction, which can be inspected later. Many years ago the OTS and CORBA Notification Service did this together.
>> 
>> If the commit/rollback fails this should be picked up by the TM recovery process - I guess that would do the job. 
>> This improves the throughput indeed, but might be confusing for users: reading the data written by a "successfully" completed transaction (i.e. TM.commit() returns without exception) would not work.
> 
> Data cannot be read until the transaction has completed (one way or another). So I'm not sure what the problem is you're alluding to here.


store.put(k,v1); //initial value
tm.begin()
store.put(k,v2);
tm.commit();

assert store.get(k).equals(v2); //this might fail with async commits, which for some users would be surprising

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)






From mmarkus at redhat.com  Tue Dec  3 09:03:46 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Tue, 3 Dec 2013 14:03:46 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <9E30661C-7036-4A42-A37A-208B8B24F2C5@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<686D0C9A-9DCA-44AE-B6C3-C4BB1B6A3D13@redhat.com>
	<8D372EA7-53BE-481A-91A8-9AEBFA217C0A@redhat.com>
	<9E30661C-7036-4A42-A37A-208B8B24F2C5@redhat.com>
Message-ID: <B96F4298-934B-490C-885B-FE6029F3CF7F@redhat.com>


On Dec 3, 2013, at 1:29 PM, Mark Little <mlittle at redhat.com> wrote:

> Oh please tell me your 1PC isn't really 2PC on multiple participants but without a prepare phase?!

This is a non-default configuration option which we plan to get rid of in ISPN 7.0. Hence this email :-)

> 
> Mark.
> 
> 
> On 29 Nov 2013, at 15:59, Mircea Markus wrote:
> 
>> On Nov 29, 2013, at 1:46 PM, Mark Little <mlittle at redhat.com> wrote:
>> 
>>> Why do you think there are no consistency guarantees? Again this may be a difference in the way you use the term 1PC versus how it's used and implemented elsewhere.
>> 
>> Indedd, 1PC here has to do with the consensus protocol used by Infinispan internally to update the same data on multiple nodes. Doesn't have to do with the XAResource.commit(xid, isOnePhase) at all (we actually plan to implement that 1PC optimization in the case a single node needs to be updated). 

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)






From mlittle at redhat.com  Wed Dec  4 06:08:34 2013
From: mlittle at redhat.com (Mark Little)
Date: Wed, 4 Dec 2013 11:08:34 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <832F2890-B944-479D-A7B0-C247B79814AF@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<1384267860.18422.126.camel@T520>
	<F8A0D59A-7E36-4CCE-95EF-696709F8EC82@redhat.com>
	<528B1766.5010909@redhat.com>
	<8E6ED5F3-9747-411D-B212-5AB9FB5CAA61@redhat.com>
	<BAY174-DS18E1CB6D3AA4753056F848C3E70@phx.gbl>
	<CA+nfvwTZBR-D701hdSyFr5yLfJEmvNu53wLpFk8tH5pR06o68Q@mail.gmail.com>
	<553828B2-4F7E-45E8-8445-CFAFBDF89E33@redhat.com>
	<CA+nfvwRWjPsm5jr7LkeeJgOyN+sk0AYXGpzYzakvNg-OKFoUPg@mail.gmail.com>
	<408CD088-1940-400C-BD09-FDF63BDF6698@redhat.com>
	<528C8BD8.9010208@infinispan.org>
	<7262CC7E-316D-47DB-B0F3-37399B30D172@redhat.com>
	<528DF53C.8030602@infinispan.org>
	<CA+nfvwQG=t7pLfcCgCqLCAws1S0thDS_zo=OHSuq_=_EC=YUyA@mail.gmail.com>
	<E9EB86AE-C238-4985-892F-4F5CED6A731D@redhat.com>
	<181E3433-D991-46E0-822F-EAAEB2BB36C6@redhat.com>
	<832F2890-B944-479D-A7B0-C247B79814AF@redhat.com>
Message-ID: <B6435FED-6E17-405D-A028-105A79F08A1A@redhat.com>

Any time you use transactions and disable recovery is a time to step back and rethink what you really need.

Mark.


On 3 Dec 2013, at 13:51, Mircea Markus wrote:

> On Dec 3, 2013, at 1:26 PM, Mark Little <mlittle at redhat.com> wrote:
> 
>> Why write a log if there is no recovery? That's wrong.
> 
> AFAIK the recovery is configured as a separate subsystem within the TM. If recovery can be disabled entirely within TM, including TM's log writes, then indeed as Dan suggested, XA resource enlisted would have the same performance as synchronization enlistments. I don't find this setup very nice though :-)
> 
>> 
>> Mark.
>> 
>> 
>> On 29 Nov 2013, at 14:39, Mircea Markus wrote:
>> 
>>> 
>>> On Nov 21, 2013, at 3:18 PM, Dan Berindei <dan.berindei at gmail.com> wrote:
>>> 
>>>> Hmm, couldn't you just disable recovery in the TM to get the same performance with a XA resource as with a synchronization?
>>>> 
>>> 
>>> I don't think that would be enough actually. Even without recovery, for transactions (XA) that have more than one participant registered, the TM writes information on the transaction log.
>>> This is a persistent log and writing to it slows down things.
>>> 
>>> 
>>>> 
>>>> On Thu, Nov 21, 2013 at 1:57 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
>>>> 
>>>> 
>>>> On 11/21/2013 11:34 AM, Galder Zamarre?o wrote:
>>>>> 
>>>>> 
>>>>> It's way faster actually. The speed difference from all the extra work required by Transaction Manager to deal with multiple XA resources, make transactions recoverable..etc. We've done tests in the past (i.e. Hibernate 2LC) comparing both and the difference was quite big.
>>>>> 
>>>> 
>>>> you are right. I forgot the recovery mechanism :)
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
>> ---
>> Mark Little
>> mlittle at redhat.com
>> 
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).






From mlittle at redhat.com  Wed Dec  4 06:09:32 2013
From: mlittle at redhat.com (Mark Little)
Date: Wed, 4 Dec 2013 11:09:32 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <90F8EBE7-B29C-4008-9A39-BFD73CB55248@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<AF2F210C-1890-41A5-B19F-3E4CA8FDA669@redhat.com>
	<3D287693-E1F4-4C8F-8605-67084C7BDD15@redhat.com>
	<B7AD62F5-5F71-4C4C-A5DA-EDDB1F24D9B1@redhat.com>
	<90F8EBE7-B29C-4008-9A39-BFD73CB55248@redhat.com>
Message-ID: <BC0B8CBA-40A3-4D08-8F6F-C072CAC0D288@redhat.com>

Agreed if fail. Alternatively it could block whilst waiting for the commit to complete.

Mark.


On 3 Dec 2013, at 13:58, Mircea Markus wrote:

>> Data cannot be read until the transaction has completed (one way or another). So I'm not sure what the problem is you're alluding to here.
> 
> 
> store.put(k,v1); //initial value
> tm.begin()
> store.put(k,v2);
> tm.commit();
> 
> assert store.get(k).equals(v2); //this might fail with async commits, which for some users would be surprising

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131204/534827dd/attachment-0001.html 

From mlittle at redhat.com  Wed Dec  4 06:10:15 2013
From: mlittle at redhat.com (Mark Little)
Date: Wed, 4 Dec 2013 11:10:15 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <B96F4298-934B-490C-885B-FE6029F3CF7F@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<686D0C9A-9DCA-44AE-B6C3-C4BB1B6A3D13@redhat.com>
	<8D372EA7-53BE-481A-91A8-9AEBFA217C0A@redhat.com>
	<9E30661C-7036-4A42-A37A-208B8B24F2C5@redhat.com>
	<B96F4298-934B-490C-885B-FE6029F3CF7F@redhat.com>
Message-ID: <65B1F6AF-35A8-4564-8E8A-8784C2ECF5EA@redhat.com>

So we do have multiple participants within a "1PC" "transaction"? Really? Seriously? Huh? WTF?

Mark.



On 3 Dec 2013, at 14:03, Mircea Markus wrote:

> 
> On Dec 3, 2013, at 1:29 PM, Mark Little <mlittle at redhat.com> wrote:
> 
>> Oh please tell me your 1PC isn't really 2PC on multiple participants but without a prepare phase?!
> 
> This is a non-default configuration option which we plan to get rid of in ISPN 7.0. Hence this email :-)
> 
>> 
>> Mark.
>> 
>> 
>> On 29 Nov 2013, at 15:59, Mircea Markus wrote:
>> 
>>> On Nov 29, 2013, at 1:46 PM, Mark Little <mlittle at redhat.com> wrote:
>>> 
>>>> Why do you think there are no consistency guarantees? Again this may be a difference in the way you use the term 1PC versus how it's used and implemented elsewhere.
>>> 
>>> Indedd, 1PC here has to do with the consensus protocol used by Infinispan internally to update the same data on multiple nodes. Doesn't have to do with the XAResource.commit(xid, isOnePhase) at all (we actually plan to implement that 1PC optimization in the case a single node needs to be updated). 
> 
> 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

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).






From mmarkus at redhat.com  Wed Dec  4 06:24:31 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Wed, 4 Dec 2013 11:24:31 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <BC0B8CBA-40A3-4D08-8F6F-C072CAC0D288@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<AF2F210C-1890-41A5-B19F-3E4CA8FDA669@redhat.com>
	<3D287693-E1F4-4C8F-8605-67084C7BDD15@redhat.com>
	<B7AD62F5-5F71-4C4C-A5DA-EDDB1F24D9B1@redhat.com>
	<90F8EBE7-B29C-4008-9A39-BFD73CB55248@redhat.com>
	<BC0B8CBA-40A3-4D08-8F6F-C072CAC0D288@redhat.com>
Message-ID: <23B19216-C6E2-4638-AD4D-694C5D83CE52@redhat.com>

Even if it doesn't fail: the commit is sent async, the get which is sync might be processed before the commit and sees the old data.


On Dec 4, 2013, at 11:09 AM, Mark Little <mlittle at redhat.com> wrote:

> Agreed if fail. Alternatively it could block whilst waiting for the commit to complete.
> 
> Mark.
> 
> 
> On 3 Dec 2013, at 13:58, Mircea Markus wrote:
> 
>>> Data cannot be read until the transaction has completed (one way or another). So I'm not sure what the problem is you're alluding to here.
>> 
>> 
>> store.put(k,v1); //initial value
>> tm.begin()
>> store.put(k,v2);
>> tm.commit();
>> 
>> assert store.get(k).equals(v2); //this might fail with async commits, which for some users would be surprising
> 
> ---
> Mark Little
> mlittle at redhat.com
> 
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
> 
> 
> 
> 
> _______________________________________________
> 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)






From mmarkus at redhat.com  Wed Dec  4 06:29:53 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Wed, 4 Dec 2013 11:29:53 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <65B1F6AF-35A8-4564-8E8A-8784C2ECF5EA@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<686D0C9A-9DCA-44AE-B6C3-C4BB1B6A3D13@redhat.com>
	<8D372EA7-53BE-481A-91A8-9AEBFA217C0A@redhat.com>
	<9E30661C-7036-4A42-A37A-208B8B24F2C5@redhat.com>
	<B96F4298-934B-490C-885B-FE6029F3CF7F@redhat.com>
	<65B1F6AF-35A8-4564-8E8A-8784C2ECF5EA@redhat.com>
Message-ID: <AE516CFE-5964-4F9C-8FD6-8182C0220017@redhat.com>

On Dec 4, 2013, at 11:10 AM, Mark Little <mlittle at redhat.com> wrote:

> So we do have multiple participants within a "1PC" "transaction"? Really? Seriously? Huh? WTF?

To clarify this:
- this is not exposed as explicit functionality
- for a certain configuration, the cache behaves like this (replication is configured *async*)
- one of the point of this email thread is disallow this configuration (transactions + *async* replication)
Thanks for the feedback.

> 
> Mark.
> 
> 
> 
> On 3 Dec 2013, at 14:03, Mircea Markus wrote:
> 
>> 
>> On Dec 3, 2013, at 1:29 PM, Mark Little <mlittle at redhat.com> wrote:
>> 
>>> Oh please tell me your 1PC isn't really 2PC on multiple participants but without a prepare phase?!
>> 
>> This is a non-default configuration option which we plan to get rid of in ISPN 7.0. Hence this email :-)
>> 
>>> 
>>> Mark.
>>> 
>>> 
>>> On 29 Nov 2013, at 15:59, Mircea Markus wrote:
>>> 
>>>> On Nov 29, 2013, at 1:46 PM, Mark Little <mlittle at redhat.com> wrote:
>>>> 
>>>>> Why do you think there are no consistency guarantees? Again this may be a difference in the way you use the term 1PC versus how it's used and implemented elsewhere.
>>>> 
>>>> Indedd, 1PC here has to do with the consensus protocol used by Infinispan internally to update the same data on multiple nodes. Doesn't have to do with the XAResource.commit(xid, isOnePhase) at all (we actually plan to implement that 1PC optimization in the case a single node needs to be updated). 
>> 
>> 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
> 
> ---
> Mark Little
> mlittle at redhat.com
> 
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
> 
> 
> 
> 
> 
> _______________________________________________
> 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)






From mlittle at redhat.com  Wed Dec  4 06:39:41 2013
From: mlittle at redhat.com (Mark Little)
Date: Wed, 4 Dec 2013 11:39:41 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <23B19216-C6E2-4638-AD4D-694C5D83CE52@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<AF2F210C-1890-41A5-B19F-3E4CA8FDA669@redhat.com>
	<3D287693-E1F4-4C8F-8605-67084C7BDD15@redhat.com>
	<B7AD62F5-5F71-4C4C-A5DA-EDDB1F24D9B1@redhat.com>
	<90F8EBE7-B29C-4008-9A39-BFD73CB55248@redhat.com>
	<BC0B8CBA-40A3-4D08-8F6F-C072CAC0D288@redhat.com>
	<23B19216-C6E2-4638-AD4D-694C5D83CE52@redhat.com>
Message-ID: <E207E99B-3D0F-4DDA-BB4C-FBCBF3182D85@redhat.com>

Yes, I understand that. My point is that in some environments where async commit is possible they also (opaquely) tie in the read requests to data such that they can block if the commit hasn't completed.

Mark.


On 4 Dec 2013, at 11:24, Mircea Markus wrote:

> Even if it doesn't fail: the commit is sent async, the get which is sync might be processed before the commit and sees the old data.
> 
> 
> On Dec 4, 2013, at 11:09 AM, Mark Little <mlittle at redhat.com> wrote:
> 
>> Agreed if fail. Alternatively it could block whilst waiting for the commit to complete.
>> 
>> Mark.
>> 
>> 
>> On 3 Dec 2013, at 13:58, Mircea Markus wrote:
>> 
>>>> Data cannot be read until the transaction has completed (one way or another). So I'm not sure what the problem is you're alluding to here.
>>> 
>>> 
>>> store.put(k,v1); //initial value
>>> tm.begin()
>>> store.put(k,v2);
>>> tm.commit();
>>> 
>>> assert store.get(k).equals(v2); //this might fail with async commits, which for some users would be surprising
>> 
>> ---
>> Mark Little
>> mlittle at redhat.com
>> 
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).






From mlittle at redhat.com  Wed Dec  4 06:40:10 2013
From: mlittle at redhat.com (Mark Little)
Date: Wed, 4 Dec 2013 11:40:10 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <AE516CFE-5964-4F9C-8FD6-8182C0220017@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<686D0C9A-9DCA-44AE-B6C3-C4BB1B6A3D13@redhat.com>
	<8D372EA7-53BE-481A-91A8-9AEBFA217C0A@redhat.com>
	<9E30661C-7036-4A42-A37A-208B8B24F2C5@redhat.com>
	<B96F4298-934B-490C-885B-FE6029F3CF7F@redhat.com>
	<65B1F6AF-35A8-4564-8E8A-8784C2ECF5EA@redhat.com>
	<AE516CFE-5964-4F9C-8FD6-8182C0220017@redhat.com>
Message-ID: <CB41F16E-0758-4592-9D2D-F98182831698@redhat.com>

Should I take this as a "yes" to my question ;-) ?

Mark.


On 4 Dec 2013, at 11:29, Mircea Markus wrote:

> On Dec 4, 2013, at 11:10 AM, Mark Little <mlittle at redhat.com> wrote:
> 
>> So we do have multiple participants within a "1PC" "transaction"? Really? Seriously? Huh? WTF?
> 
> To clarify this:
> - this is not exposed as explicit functionality
> - for a certain configuration, the cache behaves like this (replication is configured *async*)
> - one of the point of this email thread is disallow this configuration (transactions + *async* replication)
> Thanks for the feedback.
> 
>> 
>> Mark.
>> 
>> 
>> 
>> On 3 Dec 2013, at 14:03, Mircea Markus wrote:
>> 
>>> 
>>> On Dec 3, 2013, at 1:29 PM, Mark Little <mlittle at redhat.com> wrote:
>>> 
>>>> Oh please tell me your 1PC isn't really 2PC on multiple participants but without a prepare phase?!
>>> 
>>> This is a non-default configuration option which we plan to get rid of in ISPN 7.0. Hence this email :-)
>>> 
>>>> 
>>>> Mark.
>>>> 
>>>> 
>>>> On 29 Nov 2013, at 15:59, Mircea Markus wrote:
>>>> 
>>>>> On Nov 29, 2013, at 1:46 PM, Mark Little <mlittle at redhat.com> wrote:
>>>>> 
>>>>>> Why do you think there are no consistency guarantees? Again this may be a difference in the way you use the term 1PC versus how it's used and implemented elsewhere.
>>>>> 
>>>>> Indedd, 1PC here has to do with the consensus protocol used by Infinispan internally to update the same data on multiple nodes. Doesn't have to do with the XAResource.commit(xid, isOnePhase) at all (we actually plan to implement that 1PC optimization in the case a single node needs to be updated). 
>>> 
>>> 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
>> 
>> ---
>> Mark Little
>> mlittle at redhat.com
>> 
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).






From mmarkus at redhat.com  Wed Dec  4 06:46:38 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Wed, 4 Dec 2013 11:46:38 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <E207E99B-3D0F-4DDA-BB4C-FBCBF3182D85@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<AF2F210C-1890-41A5-B19F-3E4CA8FDA669@redhat.com>
	<3D287693-E1F4-4C8F-8605-67084C7BDD15@redhat.com>
	<B7AD62F5-5F71-4C4C-A5DA-EDDB1F24D9B1@redhat.com>
	<90F8EBE7-B29C-4008-9A39-BFD73CB55248@redhat.com>
	<BC0B8CBA-40A3-4D08-8F6F-C072CAC0D288@redhat.com>
	<23B19216-C6E2-4638-AD4D-694C5D83CE52@redhat.com>
	<E207E99B-3D0F-4DDA-BB4C-FBCBF3182D85@redhat.com>
Message-ID: <CCCCD78E-0507-492C-8ED1-4AAB8FA973DE@redhat.com>

On Dec 4, 2013, at 11:39 AM, Mark Little <mlittle at redhat.com> wrote:

> Yes, I understand that. My point is that in some environments where async commit is possible they also (opaquely) tie in the read requests to data such that they can block if the commit hasn't completed.

That's smart, thanks for clarifying this.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)






From mmarkus at redhat.com  Wed Dec  4 06:47:53 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Wed, 4 Dec 2013 11:47:53 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <CB41F16E-0758-4592-9D2D-F98182831698@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<686D0C9A-9DCA-44AE-B6C3-C4BB1B6A3D13@redhat.com>
	<8D372EA7-53BE-481A-91A8-9AEBFA217C0A@redhat.com>
	<9E30661C-7036-4A42-A37A-208B8B24F2C5@redhat.com>
	<B96F4298-934B-490C-885B-FE6029F3CF7F@redhat.com>
	<65B1F6AF-35A8-4564-8E8A-8784C2ECF5EA@redhat.com>
	<AE516CFE-5964-4F9C-8FD6-8182C0220017@redhat.com>
	<CB41F16E-0758-4592-9D2D-F98182831698@redhat.com>
Message-ID: <73CF71C7-9653-4777-A739-082CD970E6D5@redhat.com>

Which of your questions exactly? ;-)

On Dec 4, 2013, at 11:40 AM, Mark Little <mlittle at redhat.com> wrote:

> Should I take this as a "yes" to my question ;-) ?
> 
> Mark.
> 
> 
> On 4 Dec 2013, at 11:29, Mircea Markus wrote:
> 
>> On Dec 4, 2013, at 11:10 AM, Mark Little <mlittle at redhat.com> wrote:
>> 
>>> So we do have multiple participants within a "1PC" "transaction"? Really? Seriously? Huh? WTF?
>> 
>> To clarify this:
>> - this is not exposed as explicit functionality
>> - for a certain configuration, the cache behaves like this (replication is configured *async*)
>> - one of the point of this email thread is disallow this configuration (transactions + *async* replication)
>> Thanks for the feedback.
>> 
>>> 
>>> Mark.
>>> 
>>> 
>>> 
>>> On 3 Dec 2013, at 14:03, Mircea Markus wrote:
>>> 
>>>> 
>>>> On Dec 3, 2013, at 1:29 PM, Mark Little <mlittle at redhat.com> wrote:
>>>> 
>>>>> Oh please tell me your 1PC isn't really 2PC on multiple participants but without a prepare phase?!
>>>> 
>>>> This is a non-default configuration option which we plan to get rid of in ISPN 7.0. Hence this email :-)
>>>> 
>>>>> 
>>>>> Mark.
>>>>> 
>>>>> 
>>>>> On 29 Nov 2013, at 15:59, Mircea Markus wrote:
>>>>> 
>>>>>> On Nov 29, 2013, at 1:46 PM, Mark Little <mlittle at redhat.com> wrote:
>>>>>> 
>>>>>>> Why do you think there are no consistency guarantees? Again this may be a difference in the way you use the term 1PC versus how it's used and implemented elsewhere.
>>>>>> 
>>>>>> Indedd, 1PC here has to do with the consensus protocol used by Infinispan internally to update the same data on multiple nodes. Doesn't have to do with the XAResource.commit(xid, isOnePhase) at all (we actually plan to implement that 1PC optimization in the case a single node needs to be updated). 
>>>> 
>>>> 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
>>> 
>>> ---
>>> Mark Little
>>> mlittle at redhat.com
>>> 
>>> JBoss, by Red Hat
>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> ---
> Mark Little
> mlittle at redhat.com
> 
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
> 
> 
> 
> 
> 
> _______________________________________________
> 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)






From galder at redhat.com  Thu Dec  5 11:16:26 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Thu, 5 Dec 2013 17:16:26 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
Message-ID: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>

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 have another read and let the list know what you think of it?

Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.

Cheers,
--
Galder Zamarre?o
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org



From rvansa at redhat.com  Fri Dec  6 04:45:39 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 06 Dec 2013 10:45:39 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
Message-ID: <52A19CC3.40807@redhat.com>

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 server-wise 
whether you should ack each / only last event sounds weird. I'd replace 
the boolean with enum { NO_ACK, ACK_EACH, ACK_LAST }.

3) should the client provide source id when registering listener or when 
starting RemoteCacheManager? No API for that.

4) clustered events design does not specify any means to replicating the 
clustered event listener - all it does is that you register the listener 
on one node and the other nodes then route events to this node, until 
the node dies/deregisters the listener. No replication. Please specify, 
how should it piggyback on clustered events, and how should the listener 
list be replicated.

5) non-acked events: how exactly do you expect the ack data to be 
replicated, and updated? I see three options:
A) Let non-acked list be a part of the listener record in replicated 
cache, and the primary owner which executes the event should update 
these via delta messages. I guess for proper reliability it should add 
operation record synchronously before confirming the operation to the 
originator, and then it might asynchronously remove it after the ack 
from client. When a node becomes primary owner, it should send events to 
client for all non-acked events.
B) Having the non-acked list attached directly to cache entry (updating 
it together with regular backup), and then asynchronously updating the 
non-ack list after ack comes
C) Separate cache for acks by entry keys, similar to B, consistent hash 
synced with the main entry cache

Radim


On 12/05/2013 05:16 PM, Galder Zamarre?o wrote:
> 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 have another read and let the list know what you think of it?
>
> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
>
> Cheers,
> --
> Galder Zamarre?o
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA


From mmarkus at redhat.com  Fri Dec  6 08:30:18 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Fri, 6 Dec 2013 13:30:18 +0000
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
Message-ID: <E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>

+ infinispan-dev

Thanks for offering to look into this Brett!
We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
Tristan can get you up to speed with this.


>> Sanne/Galder/Pete,
>> 
>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>> 
>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>> 
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>> 
> 

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)






From mmarkus at redhat.com  Fri Dec  6 09:52:00 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Fri, 6 Dec 2013 14:52:00 +0000
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
Message-ID: <7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>

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 discussions, you've also mentioned that you'd want to use the cluster listeners as a foundation for this functionality. That doesn't seem to be the case from the document, or? Not that it's a bad thing, just that I want to clarify the relation between the two. Another way to handle connection management, based on clustered listeners, would be:
- the node on which the listeners ID hashes is the only one responsible for piggyback notifications to the remote client
- it creates a cluster listener to be notified on what to send to the client (can make use cluster listener's filtering and transformer capabilities here)

Comparing the two approaches: this approach reuses some code (not sure how much, we might be able to do that anyway) from the cluster listeners and also reduces the number of connections required between clint and server, but at the cost of performance/network hops. Also the number of connections a client is required to have hasn't been a problem yet.

One more note on ST: during ST a node might receive the same notification multiple times (from old owner and new owner). I guess it makes sense documenting that?

On Dec 5, 2013, at 4:16 PM, Galder Zamarre?o <galder at redhat.com> wrote:

> 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 have another read and let the list know what you think of it?
> 
> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.

+1. Can we include the notification ack in the optionals category?
What about leaving these as the last bit to be implemented? If time allows (not to delay the release) we can add them, otherwise just add them in future iterations?


> 
> Cheers,
> --
> Galder Zamarre?o
> galder at redhat.com
> twitter.com/galderz
> 
> Project Lead, Escalante
> http://escalante.io
> 
> Engineer, Infinispan
> http://infinispan.org
> 

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)






From ben.cotton at jpmorgan.com  Fri Dec  6 10:11:06 2013
From: ben.cotton at jpmorgan.com (ben.cotton)
Date: Fri, 6 Dec 2013 07:11:06 -0800 (PST)
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <CCCCD78E-0507-492C-8ED1-4AAB8FA973DE@redhat.com>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<AF2F210C-1890-41A5-B19F-3E4CA8FDA669@redhat.com>
	<3D287693-E1F4-4C8F-8605-67084C7BDD15@redhat.com>
	<B7AD62F5-5F71-4C4C-A5DA-EDDB1F24D9B1@redhat.com>
	<90F8EBE7-B29C-4008-9A39-BFD73CB55248@redhat.com>
	<BC0B8CBA-40A3-4D08-8F6F-C072CAC0D288@redhat.com>
	<23B19216-C6E2-4638-AD4D-694C5D83CE52@redhat.com>
	<E207E99B-3D0F-4DDA-BB4C-FBCBF3182D85@redhat.com>
	<CCCCD78E-0507-492C-8ED1-4AAB8FA973DE@redhat.com>
Message-ID: <5E52BF1ABBD2A64986C1CB3D207DAB0606F43C24@SEGCMX039.exchad.jpmchase.net>

?  That's smart, thanks for clarifying this.

It is smart.  And for some necessary ...  implementing READ_COMMITTED as "block til their done" pays homage to the in-flight transactions' ambitions to update.  Implementing READ_COMMITTED as "just give readers the old data" pays ZERO homage to the in-flight transactions' ambitions to update.

Even better would be exposing some kind of API that empowers the user to specify READ_COMMITTED with either policy.

i.e.    accommodate both potential user isolation choices via some kind of

.setTxIsolation(READ_COMMITTED,  READERS_GET_OLD_DATA);  //pessimistic wrt to in-flight tx?
.setTxIsolation READ_COMMITTED,  READERS_BLOCK_UNTIL_IN_FLIGHT_TXS_OUTCOME); //optimistic wrt to in-flight tx?

API capability

Does ISPN transactions offering have the ambition to provide both in the API?





From: Mircea Markus-2 [via Infinispan Developer List] [mailto:ml-node+s980875n4028545h88 at n3.nabble.com]
Sent: Wednesday, December 04, 2013 6:47 AM
To: Cotton, Ben
Subject: Re: [infinispan-dev] rethinking ISPN transactions

On Dec 4, 2013, at 11:39 AM, Mark Little <[hidden email]</user/SendEmail.jtp?type=node&node=4028545&i=0>> wrote:

> Yes, I understand that. My point is that in some environments where async commit is possible they also (opaquely) tie in the read requests to data such that they can block if the commit hasn't completed.

That's smart, thanks for clarifying this.

Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)





_______________________________________________
infinispan-dev mailing list
[hidden email]</user/SendEmail.jtp?type=node&node=4028545&i=1>
https://lists.jboss.org/mailman/listinfo/infinispan-dev

________________________________
If you reply to this email, your message will be added to the discussion below:
http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-rethinking-ISPN-transactions-tp4028325p4028545.html
To start a new topic under Infinispan Developer List, email ml-node+s980875n2085493h76 at n3.nabble.com
To unsubscribe from Infinispan Developer List, click here<http://infinispan-developer-list.980875.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2085493&code=YmVuLmNvdHRvbkBqcG1vcmdhbi5jb218MjA4NTQ5M3wyNjQyNTgwNjE=>.
NAML<http://infinispan-developer-list.980875.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.




--
View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-rethinking-ISPN-transactions-tp4028325p4028551.html
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131206/24550286/attachment-0001.html 

From rvansa at redhat.com  Fri Dec  6 10:17:22 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 06 Dec 2013 16:17:22 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
Message-ID: <52A1EA82.3000500@redhat.com>

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 Cpp clients independently.
Is a new intelligence level required? Protocol 1.4 should specify a bit 
flag "carrying SourceID/not carrying SourceID". If the client is dumb, 
it simply leaves the flag to default and as it won't register any 
listener, the server wont bother him with any new information. If it 
starts registering listeners, the server should start sending events. We 
may speak about it as L4, if you wish, but there's no need to add new 
intelligence level to the protocol.

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 about its own change?

Radim
>
> In one of our discussions, you've also mentioned that you'd want to use the cluster listeners as a foundation for this functionality. That doesn't seem to be the case from the document, or? Not that it's a bad thing, just that I want to clarify the relation between the two. Another way to handle connection management, based on clustered listeners, would be:
> - the node on which the listeners ID hashes is the only one responsible for piggyback notifications to the remote client
> - it creates a cluster listener to be notified on what to send to the client (can make use cluster listener's filtering and transformer capabilities here)
>
> Comparing the two approaches: this approach reuses some code (not sure how much, we might be able to do that anyway) from the cluster listeners and also reduces the number of connections required between clint and server, but at the cost of performance/network hops. Also the number of connections a client is required to have hasn't been a problem yet.
>
> One more note on ST: during ST a node might receive the same notification multiple times (from old owner and new owner). I guess it makes sense documenting that?
>
> On Dec 5, 2013, at 4:16 PM, Galder Zamarre?o <galder at redhat.com> wrote:
>
>> 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 have another read and let the list know what you think of it?
>>
>> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
> +1. Can we include the notification ack in the optionals category?
> What about leaving these as the last bit to be implemented? If time allows (not to delay the release) we can add them, otherwise just add them in future iterations?
>
>
>> Cheers,
>> --
>> Galder Zamarre?o
>> galder at redhat.com
>> twitter.com/galderz
>>
>> Project Lead, Escalante
>> http://escalante.io
>>
>> Engineer, Infinispan
>> http://infinispan.org
>>
> Cheers,


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA


From mmarkus at redhat.com  Fri Dec  6 10:23:59 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Fri, 6 Dec 2013 15:23:59 +0000
Subject: [infinispan-dev] rethinking ISPN transactions
In-Reply-To: <5E52BF1ABBD2A64986C1CB3D207DAB0606F43C24@SEGCMX039.exchad.jpmchase.net>
References: <7C2E04BF-A923-4E41-80A6-28593214993A@redhat.com>
	<AF2F210C-1890-41A5-B19F-3E4CA8FDA669@redhat.com>
	<3D287693-E1F4-4C8F-8605-67084C7BDD15@redhat.com>
	<B7AD62F5-5F71-4C4C-A5DA-EDDB1F24D9B1@redhat.com>
	<90F8EBE7-B29C-4008-9A39-BFD73CB55248@redhat.com>
	<BC0B8CBA-40A3-4D08-8F6F-C072CAC0D288@redhat.com>
	<23B19216-C6E2-4638-AD4D-694C5D83CE52@redhat.com>
	<E207E99B-3D0F-4DDA-BB4C-FBCBF3182D85@redhat.com>
	<CCCCD78E-0507-492C-8ED1-4AAB8FA973DE@redhat.com>
	<5E52BF1ABBD2A64986C1CB3D207DAB0606F43C24@SEGCMX039.exchad.jpmchase.net>
Message-ID: <AEA34016-CDC4-4AE8-9487-E6C063832499@redhat.com>


On Dec 6, 2013, at 3:11 PM, ben.cotton <ben.cotton at jpmorgan.com> wrote:

> ?  That's smart, thanks for clarifying this.
> 
>  
> 
> It is smart.  And for some necessary ?  implementing READ_COMMITTED as ?block til their done? pays homage to the in-flight transactions? ambitions to update.  Implementing READ_COMMITTED as ?just give readers the old data? pays ZERO homage to the in-flight transactions? ambitions to update.
> 
>  
> 
> Even better would be exposing some kind of API that empowers the user to specify READ_COMMITTED with either policy.
> 
>  
> 
> i.e.    accommodate both potential user isolation choices via some kind of
> 
>  
> 
> .setTxIsolation(READ_COMMITTED,  READERS_GET_OLD_DATA);  //pessimistic wrt to in-flight tx?
> 
> .setTxIsolation READ_COMMITTED,  READERS_BLOCK_UNTIL_IN_FLIGHT_TXS_OUTCOME); //optimistic wrt to in-flight tx?
> 
>  
> 
> API capability
> 
>  
> 
> Does ISPN transactions offering have the ambition to provide both in the API?


This option makes sense as a performance optimization, indeed. I don't think there's immediate need for it, but definitely something to hold in mind for the future. 



> From: Mircea Markus-2 [via Infinispan Developer List] [mailto:ml-node+[hidden email]] 
> Sent: Wednesday, December 04, 2013 6:47 AM
> To: Cotton, Ben
> Subject: Re: [infinispan-dev] rethinking ISPN transactions
> 
>  
> 
> On Dec 4, 2013, at 11:39 AM, Mark Little <[hidden email]> wrote: 
> 
> > Yes, I understand that. My point is that in some environments where async commit is possible they also (opaquely) tie in the read requests to data such that they can block if the commit hasn't completed. 
> 
> That's smart, thanks for clarifying this. 
> 
> Cheers, 
> -- 
> Mircea Markus 
> Infinispan lead (www.infinispan.org) 
> 
> 
> 
> 
> 
> _______________________________________________ 
> infinispan-dev mailing list 
> [hidden email] 
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> If you reply to this email, your message will be added to the discussion below:
> 
> http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-rethinking-ISPN-transactions-tp4028325p4028545.html
> 
> To start a new topic under Infinispan Developer List, email ml-node+[hidden email] 
> To unsubscribe from Infinispan Developer List, click here.
> NAML
> 
> This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
> 
> 
> View this message in context: RE: [infinispan-dev] rethinking ISPN transactions
> Sent from the Infinispan Developer List mailing list archive at Nabble.com.
> _______________________________________________
> 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)






From rhauch at redhat.com  Fri Dec  6 10:57:23 2013
From: rhauch at redhat.com (Randall Hauch)
Date: Fri, 6 Dec 2013 09:57:23 -0600
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
Message-ID: <05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>

Brett, correct me if I?m wrong, but isn?t there a difference in making some library *work* in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled application? For example, making the JAR?s be OSGi bundles is easy and technically makes it possible to deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC what you really want is a BundleActivator or Declarative Services [1] so that the library?s components are readily available in a naturally-OSGi way.

[1] http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html

On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:

> + infinispan-dev
> 
> Thanks for offering to look into this Brett!
> We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
> Tristan can get you up to speed with this.
> 
> 
>>> Sanne/Galder/Pete,
>>> 
>>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>> 
>>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>>> 
>>> Brett Meyer
>>> Software Engineer
>>> Red Hat, Hibernate ORM
>>> 
>> 
> 
> 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



From balazs.zsoldos at everit.biz  Fri Dec  6 11:18:36 2013
From: balazs.zsoldos at everit.biz (=?ISO-8859-1?Q?Bal=E1zs_Zsoldos?=)
Date: Fri, 6 Dec 2013 17:18:36 +0100
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
Message-ID: <CAHEBw=QLdiaLZBQUU28o7D-_f1K17PxuB2nu1BJ4UqC2RFtREA@mail.gmail.com>

Hi,

you might be interested that we work on this. We have just created an OSGi
Declarative Services component that uses the latest Infinispan-JCache code.
Well, this component is pretty primitive, there are only a couple of
configuration possibilities:
 - Clustername
 - IP
 - Port

The interface of the service that the Component implements has only one
function:

 - Cache createCache(cacheConfiguration);

cacheConfiguration contains some possibilities like the type
(distributed/replicated), maxIdle, maxEntries, ...

We had only one problem till now. The infinispan-jcache wired to the
javax.enterprise.context and some other packages, although we do not use
them in the OSGi world. We made them optional in the MANIFEST.MF and
uploaded it to our maven repository.

The component will be released very soon (within days) at GitHub. It will
be part of our OpenSource framework. Every other components will be able to
create caches for themselves based on the cacheFactory component.

If you are interested, I will keep you up-to-date on this mailing list.

Btw.: This is the MANIFEST we use in infinispan-jcache that made everything
work (till now) (look for the word "optional" to see what we had to
change):

Import-Package: javax.cache;version="[1.0,2)",javax.cache.annotation;ver
 sion="[1.0,2)",javax.cache.configuration,javax.cache.event;version="[1.
 0,2)",javax.cache.expiry,javax.cache.integration,javax.cache.management
 ,javax.cache.processor,javax.cache.spi;version="[1.0,2)",javax.enterpri
 se.context;resolution:=optional,javax.enterprise.context.spi;resolution
 :=optional,javax.enterprise.event;resolution:=optional,javax.enterprise
 .inject;resolution:=optional,javax.enterprise.inject.spi;resolution:=op
 tional,javax.inject;resolution:=optional,javax.interceptor;resolution:=
 optional,javax.management,javax.naming,javax.transaction;version="[1.1,
 2)",javax.transaction.xa;version="[1.1,2)",javax.xml.namespace,org.infi
 nispan;version="[6.0,7)",org.infinispan.cdi;resolution:=optional;versio
 n="[6.0,7)",org.infinispan.commands;version="[6.0,7)",org.infinispan.co
 mmands.read;version="[6.0,7)",org.infinispan.commands.tx;version="[6.0,
 7)",org.infinispan.commons;version="[6.0,7)",org.infinispan.commons.api
 ;version="[6.0,7)",org.infinispan.commons.configuration;version="[6.0,7
 )",org.infinispan.commons.marshall;version="[6.0,7)",org.infinispan.com
 mons.util;version="[6.0,7)",org.infinispan.commons.util.concurrent;vers
 ion="[6.0,7)",org.infinispan.configuration.cache;version="[6.0,7)",org.
 infinispan.configuration.global;version="[6.0,7)",org.infinispan.config
 uration.parsing;version="[6.0,7)",org.infinispan.container;version="[6.
 0,7)",org.infinispan.container.entries;version="[6.0,7)",org.infinispan
 .container.versioning;version="[6.0,7)",org.infinispan.context;version=
 "[6.0,7)",org.infinispan.factories;version="[6.0,7)",org.infinispan.int
 erceptors;version="[6.0,7)",org.infinispan.interceptors.base;version="[
 6.0,7)",org.infinispan.jmx;version="[6.0,7)",org.infinispan.lifecycle;v
 ersion="[6.0,7)",org.infinispan.manager;version="[6.0,7)",org.infinispa
 n.marshall.core;version="[6.0,7)",org.infinispan.metadata;version="[6.0
 ,7)",org.infinispan.notifications;version="[6.0,7)",org.infinispan.noti
 fications.cachelistener.annotation;version="[6.0,7)",org.infinispan.not
 ifications.cachelistener.event;version="[6.0,7)",org.infinispan.persist
 ence.manager;version="[6.0,7)",org.infinispan.persistence.spi;version="
 [6.0,7)",org.infinispan.persistence.support;version="[6.0,7)",org.infin
 ispan.remoting;version="[6.0,7)",org.infinispan.remoting.transport;vers
 ion="[6.0,7)",org.infinispan.remoting.transport.jgroups;version="[6.0,7
 )",org.infinispan.stats;version="[6.0,7)",org.infinispan.transaction;ve
 rsion="[6.0,7)",org.infinispan.transaction.xa;version="[6.0,7)",org.inf
 inispan.transaction.xa.recovery;version="[6.0,7)",org.infinispan.util;v
 ersion="[6.0,7)",org.infinispan.util.concurrent;version="[6.0,7)",org.i
 nfinispan.util.concurrent.locks.containers;version="[6.0,7)",org.infini
 span.util.logging;version="[6.0,7)",org.jboss.logging;version="[3.1,4)"
 ,org.jgroups;version="[3.4,4)"

Regards,

Balazs Zsoldos
Software Architect
Mobile: +36-70/594-92-34

Everit Kft.
https://www.everit.biz

Everit OpenSource
http://everit.org


On Fri, Dec 6, 2013 at 4:57 PM, Randall Hauch <rhauch at redhat.com> wrote:

> Brett, correct me if I?m wrong, but isn?t there a difference in making
> some library *work* in an OSGi environment and making that library
> *naturally fit well* in an OSGi-enabled application? For example, making
> the JAR?s be OSGi bundles is easy and technically makes it possible to
> deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC
> what you really want is a BundleActivator or Declarative Services [1] so
> that the library?s components are readily available in a naturally-OSGi way.
>
> [1]
> http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html
>
> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>
> > + infinispan-dev
> >
> > Thanks for offering to look into this Brett!
> > We're already producing OSGi bundles for our modules, but these are not
> tested extensively so if you'd review them and test them a bit would be
> great!
> > Tristan can get you up to speed with this.
> >
> >
> >>> Sanne/Galder/Pete,
> >>>
> >>> Random question: what's the current state of making Infinispan OSGi
> friendly?  I'm definitely interested in helping, if it's still a need.
>  This past year, I went through the exercise of making Hibernate work well
> in OSGi, so all of challenges (read: *many* of them) are still fairly fresh
> on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
> >>>
> >>> If you're up for it, fill me in?  I'm happy to pull everything down
> and start working with it.
> >>>
> >>> Brett Meyer
> >>> Software Engineer
> >>> Red Hat, Hibernate ORM
> >>>
> >>
> >
> > 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
>
>
> _______________________________________________
> 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/20131206/5038661e/attachment-0001.html 

From mmarkus at redhat.com  Fri Dec  6 11:18:40 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Fri, 6 Dec 2013 16:18:40 +0000
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <529F6374.3070901@redhat.com>
References: <529F6374.3070901@redhat.com>
Message-ID: <D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>

Thanks Vladimir, I like the hands on approach! 
Adding -dev, there's a lot of interest around the parallel M/R so I think others will have some thoughts on it as well.

So what you're basically doing in your branch is iterate over all the keys in the cache and then for each key invoke the mapping in a separate thread. Whilst this would work, I think it has some drawbacks:
- the iteration over the keys in the container happens in sequence, albeit the mapping phases happening in parallel. This speeds things up a bit but not as much as having the iteration 
happening in parallel, especially when the mapper is fast, which I think it's pretty common.
- the StatelessTask + some smaller objects are being created for each iterated key. That's a lot of noise for the GC imo

I think delegating the parallel iteration to the DataContainer (similar to AdvancedCacheLoader.process (Executor)) would be a better approach IMO:
- the logic is reusable for other components as well, such as querying (to implement full-scan-like search, or a general purpose parallel iterator over the keys
- object creation is reduced
- the DefaultDetaContainer uses an EquivalentConcurrentHashMapV8 for holding the entries, which already supports parallel iteration so the heavy lifting is already in place

On Dec 4, 2013, at 5:16 PM, Vladimir Blagojevic <vblagoje at redhat.com> wrote:

> Here is my M/R parallel execution solution updated to master https://github.com/vblagoje/infinispan/tree/t_2284_new
> 
> Now, I'll work on your solution which I am starting to like actually the more I think about it. Although I have to admit that I would eviscerate some of your interfaces like these KeyFilters into more prominent packages so we can all use the same interfaces. Also I would see if we can genericize some of your interfaces and implementations.
> 
> Will keep you updated.
> 
> Vladimir

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)






From vblagoje at redhat.com  Fri Dec  6 11:36:52 2013
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Fri, 06 Dec 2013 11:36:52 -0500
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
References: <529F6374.3070901@redhat.com>
	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
Message-ID: <52A1FD24.7000007@redhat.com>

Hey Mircea,

On the right track but not exactly. I do not use separate thread per 
key. Input keys for map/combine/reduce are split into a List of Lists 
and then each lists is submitted to Executor as a separate Runnable. 
Have a look at submitToExecutor method on 
https://github.com/vblagoje/infinispan/tree/t_2284_new

What I intend to do is move this code to DataContainer because the 
minimal overhead of directly iterating keys inside container and 
iterating in parallel should gives a further edge.

Stay tuned,
Vladimir

On 12/6/2013, 11:18 AM, Mircea Markus wrote:
> Thanks Vladimir, I like the hands on approach!
> Adding -dev, there's a lot of interest around the parallel M/R so I think others will have some thoughts on it as well.
>
> So what you're basically doing in your branch is iterate over all the keys in the cache and then for each key invoke the mapping in a separate thread. Whilst this would work, I think it has some drawbacks:
> - the iteration over the keys in the container happens in sequence, albeit the mapping phases happening in parallel. This speeds things up a bit but not as much as having the iteration
> happening in parallel, especially when the mapper is fast, which I think it's pretty common.
> - the StatelessTask + some smaller objects are being created for each iterated key. That's a lot of noise for the GC imo
>
> I think delegating the parallel iteration to the DataContainer (similar to AdvancedCacheLoader.process (Executor)) would be a better approach IMO:
> - the logic is reusable for other components as well, such as querying (to implement full-scan-like search, or a general purpose parallel iterator over the keys
> - object creation is reduced
> - the DefaultDetaContainer uses an EquivalentConcurrentHashMapV8 for holding the entries, which already supports parallel iteration so the heavy lifting is already in place
>
> On Dec 4, 2013, at 5:16 PM, Vladimir Blagojevic <vblagoje at redhat.com> wrote:
>
>> Here is my M/R parallel execution solution updated to master https://github.com/vblagoje/infinispan/tree/t_2284_new
>>
>> Now, I'll work on your solution which I am starting to like actually the more I think about it. Although I have to admit that I would eviscerate some of your interfaces like these KeyFilters into more prominent packages so we can all use the same interfaces. Also I would see if we can genericize some of your interfaces and implementations.
>>
>> Will keep you updated.
>>
>> Vladimir
> Cheers,


From mmarkus at redhat.com  Fri Dec  6 11:40:39 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Fri, 6 Dec 2013 16:40:39 +0000
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <52A1FD24.7000007@redhat.com>
References: <529F6374.3070901@redhat.com>
	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
	<52A1FD24.7000007@redhat.com>
Message-ID: <59C835EB-E2C6-4EA0-BB1A-DCE4F5D182DB@redhat.com>


On Dec 6, 2013, at 4:36 PM, Vladimir Blagojevic <vblagoje at redhat.com> wrote:

> Hey Mircea,
> 
> On the right track but not exactly. I do not use separate thread per 
> key. Input keys for map/combine/reduce are split into a List of Lists 
> and then each lists is submitted to Executor as a separate Runnable. 
> Have a look at submitToExecutor method on 
> https://github.com/vblagoje/infinispan/tree/t_2284_new

Ah right. Still for each key an StatelessTask instance is created though.

> 
> What I intend to do is move this code to DataContainer because the 
> minimal overhead of directly iterating keys inside container and 
> iterating in parallel should gives a further edge.

Hmm I think you could leverage the parallel iteration from the EquivalentConcurrentHashMapV8 there instead of writing it yourself ;)

> 
> Stay tuned,
> Vladimir
> 
> On 12/6/2013, 11:18 AM, Mircea Markus wrote:
>> Thanks Vladimir, I like the hands on approach!
>> Adding -dev, there's a lot of interest around the parallel M/R so I think others will have some thoughts on it as well.
>> 
>> So what you're basically doing in your branch is iterate over all the keys in the cache and then for each key invoke the mapping in a separate thread. Whilst this would work, I think it has some drawbacks:
>> - the iteration over the keys in the container happens in sequence, albeit the mapping phases happening in parallel. This speeds things up a bit but not as much as having the iteration
>> happening in parallel, especially when the mapper is fast, which I think it's pretty common.
>> - the StatelessTask + some smaller objects are being created for each iterated key. That's a lot of noise for the GC imo
>> 
>> I think delegating the parallel iteration to the DataContainer (similar to AdvancedCacheLoader.process (Executor)) would be a better approach IMO:
>> - the logic is reusable for other components as well, such as querying (to implement full-scan-like search, or a general purpose parallel iterator over the keys
>> - object creation is reduced
>> - the DefaultDetaContainer uses an EquivalentConcurrentHashMapV8 for holding the entries, which already supports parallel iteration so the heavy lifting is already in place
>> 
>> On Dec 4, 2013, at 5:16 PM, Vladimir Blagojevic <vblagoje at redhat.com> wrote:
>> 
>>> Here is my M/R parallel execution solution updated to master https://github.com/vblagoje/infinispan/tree/t_2284_new
>>> 
>>> Now, I'll work on your solution which I am starting to like actually the more I think about it. Although I have to admit that I would eviscerate some of your interfaces like these KeyFilters into more prominent packages so we can all use the same interfaces. Also I would see if we can genericize some of your interfaces and implementations.
>>> 
>>> Will keep you updated.
>>> 
>>> Vladimir
>> Cheers,
> 
> _______________________________________________
> 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)






From pedro at infinispan.org  Fri Dec  6 11:42:40 2013
From: pedro at infinispan.org (Pedro Ruivo)
Date: Fri, 06 Dec 2013 16:42:40 +0000
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
References: <529F6374.3070901@redhat.com>
	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
Message-ID: <52A1FE80.5030500@infinispan.org>



On 12/06/2013 04:18 PM, Mircea Markus wrote:

> - the DefaultDetaContainer uses an EquivalentConcurrentHashMapV8 for holding the entries, which already supports parallel iteration so the heavy lifting is already in place
>

not entirely true. If we configure size-based eviction, the 
DefaultDataContainer uses the BoundedConcurrentHashMap.

From vblagoje at redhat.com  Fri Dec  6 11:52:19 2013
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Fri, 06 Dec 2013 11:52:19 -0500
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <59C835EB-E2C6-4EA0-BB1A-DCE4F5D182DB@redhat.com>
References: <529F6374.3070901@redhat.com>	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>	<52A1FD24.7000007@redhat.com>
	<59C835EB-E2C6-4EA0-BB1A-DCE4F5D182DB@redhat.com>
Message-ID: <52A200C3.6050400@redhat.com>

Hey Mircea,

On 12/6/2013, 11:40 AM, Mircea Markus wrote:
> Ah right. Still for each key an StatelessTask instance is created though. 

I don't think this is the case. There is one StatelessTask per 
map/reduce/combine invocation.

>> What I intend to do is move this code to DataContainer because the
>> minimal overhead of directly iterating keys inside container and
>> iterating in parallel should gives a further edge.
> Hmm I think you could leverage the parallel iteration from the EquivalentConcurrentHashMapV8 there instead of writing it yourself ;)
>

Yeah, I have to look that up. I kinda missed the whole evolution of 
ConcurrentHashMapV8.

Vladimir

From brmeyer at redhat.com  Fri Dec  6 11:51:33 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Fri, 6 Dec 2013 11:51:33 -0500 (EST)
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
Message-ID: <1378853890.25611986.1386348693503.JavaMail.root@redhat.com>

Randall, that is *definitely* the case and is certainly true for Hibernate.  The work involved:

* correctly resolving ClassLoaders based on the activated bundles
* supporting multiple containers and contexts (container-managed JPA, un-managed JPA/native, etc.)
* fully supporting OSGi/Blueprint services (both for internal services as well as externally-registered)
* bundle scanning
* generally working towards supporting the dynamic nature
* full unit-tests with Arquillian and an OSGi container

It's a matter of holistically supporting the "OSGi way" (for better or worse), as opposed to simply ensuring the library's manifest is correct.

There were a bloody ton of gotchas and caveats I hit along the way.  That's more along the lines of where I might be able to help.

I'm even more interested in this effort so that we can support hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I hit  ClassLoader issues [1].  Some of that may already be resolved.

The next step may simply be giving hibernate-infinispan another shot and correcting things as I find them.  In parallel, feel free to let me know if there's anything else!  ORM supports lots of OSGi-enabled extension points, etc. that are powerful for users, but obviously I don't have the Infinispan knowledge to know what would be necessary.

Thanks!

Brett Meyer
Software Engineer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Randall Hauch" <rhauch at redhat.com>
To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
Sent: Friday, December 6, 2013 10:57:23 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi

Brett, correct me if I?m wrong, but isn?t there a difference in making some library *work* in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled application? For example, making the JAR?s be OSGi bundles is easy and technically makes it possible to deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC what you really want is a BundleActivator or Declarative Services [1] so that the library?s components are readily available in a naturally-OSGi way.

[1] http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html

On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:

> + infinispan-dev
> 
> Thanks for offering to look into this Brett!
> We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
> Tristan can get you up to speed with this.
> 
> 
>>> Sanne/Galder/Pete,
>>> 
>>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>> 
>>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>>> 
>>> Brett Meyer
>>> Software Engineer
>>> Red Hat, Hibernate ORM
>>> 
>> 
> 
> 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



From brmeyer at redhat.com  Fri Dec  6 11:56:42 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Fri, 6 Dec 2013 11:56:42 -0500 (EST)
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
Message-ID: <2084410860.25622457.1386349002612.JavaMail.root@redhat.com>

Sorry, forgot the link:

[1] https://hibernate.atlassian.net/browse/HHH-8214

Brett Meyer
Software Engineer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Brett Meyer" <brmeyer at redhat.com>
To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
Sent: Friday, December 6, 2013 11:51:33 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi

Randall, that is *definitely* the case and is certainly true for Hibernate.  The work involved:

* correctly resolving ClassLoaders based on the activated bundles
* supporting multiple containers and contexts (container-managed JPA, un-managed JPA/native, etc.)
* fully supporting OSGi/Blueprint services (both for internal services as well as externally-registered)
* bundle scanning
* generally working towards supporting the dynamic nature
* full unit-tests with Arquillian and an OSGi container

It's a matter of holistically supporting the "OSGi way" (for better or worse), as opposed to simply ensuring the library's manifest is correct.

There were a bloody ton of gotchas and caveats I hit along the way.  That's more along the lines of where I might be able to help.

I'm even more interested in this effort so that we can support hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I hit  ClassLoader issues [1].  Some of that may already be resolved.

The next step may simply be giving hibernate-infinispan another shot and correcting things as I find them.  In parallel, feel free to let me know if there's anything else!  ORM supports lots of OSGi-enabled extension points, etc. that are powerful for users, but obviously I don't have the Infinispan knowledge to know what would be necessary.

Thanks!

Brett Meyer
Software Engineer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Randall Hauch" <rhauch at redhat.com>
To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
Sent: Friday, December 6, 2013 10:57:23 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi

Brett, correct me if I?m wrong, but isn?t there a difference in making some library *work* in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled application? For example, making the JAR?s be OSGi bundles is easy and technically makes it possible to deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC what you really want is a BundleActivator or Declarative Services [1] so that the library?s components are readily available in a naturally-OSGi way.

[1] http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html

On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:

> + infinispan-dev
> 
> Thanks for offering to look into this Brett!
> We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
> Tristan can get you up to speed with this.
> 
> 
>>> Sanne/Galder/Pete,
>>> 
>>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>> 
>>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>>> 
>>> Brett Meyer
>>> Software Engineer
>>> Red Hat, Hibernate ORM
>>> 
>> 
> 
> 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



From rhauch at redhat.com  Fri Dec  6 12:31:06 2013
From: rhauch at redhat.com (Randall Hauch)
Date: Fri, 6 Dec 2013 11:31:06 -0600
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
	<2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
Message-ID: <65CD86CD-B6DD-45C6-BC30-79B0523550A4@redhat.com>

I?d love to see this work proceed for Infinispan, since we want to do the same thing for ModeShape, which uses (but does not hide or encapsulate) Infinispan.


On Dec 6, 2013, at 10:56 AM, Brett Meyer <brmeyer at redhat.com> wrote:

> Sorry, forgot the link:
> 
> [1] https://hibernate.atlassian.net/browse/HHH-8214
> 
> Brett Meyer
> Software Engineer
> Red Hat, Hibernate ORM
> 
> ----- Original Message -----
> From: "Brett Meyer" <brmeyer at redhat.com>
> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
> Sent: Friday, December 6, 2013 11:51:33 AM
> Subject: Re: [infinispan-dev] help with Infinispan OSGi
> 
> Randall, that is *definitely* the case and is certainly true for Hibernate.  The work involved:
> 
> * correctly resolving ClassLoaders based on the activated bundles
> * supporting multiple containers and contexts (container-managed JPA, un-managed JPA/native, etc.)
> * fully supporting OSGi/Blueprint services (both for internal services as well as externally-registered)
> * bundle scanning
> * generally working towards supporting the dynamic nature
> * full unit-tests with Arquillian and an OSGi container
> 
> It's a matter of holistically supporting the "OSGi way" (for better or worse), as opposed to simply ensuring the library's manifest is correct.
> 
> There were a bloody ton of gotchas and caveats I hit along the way.  That's more along the lines of where I might be able to help.
> 
> I'm even more interested in this effort so that we can support hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I hit  ClassLoader issues [1].  Some of that may already be resolved.
> 
> The next step may simply be giving hibernate-infinispan another shot and correcting things as I find them.  In parallel, feel free to let me know if there's anything else!  ORM supports lots of OSGi-enabled extension points, etc. that are powerful for users, but obviously I don't have the Infinispan knowledge to know what would be necessary.
> 
> Thanks!
> 
> Brett Meyer
> Software Engineer
> Red Hat, Hibernate ORM
> 
> ----- Original Message -----
> From: "Randall Hauch" <rhauch at redhat.com>
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
> Sent: Friday, December 6, 2013 10:57:23 AM
> Subject: Re: [infinispan-dev] help with Infinispan OSGi
> 
> Brett, correct me if I?m wrong, but isn?t there a difference in making some library *work* in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled application? For example, making the JAR?s be OSGi bundles is easy and technically makes it possible to deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC what you really want is a BundleActivator or Declarative Services [1] so that the library?s components are readily available in a naturally-OSGi way.
> 
> [1] http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html
> 
> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:
> 
>> + infinispan-dev
>> 
>> Thanks for offering to look into this Brett!
>> We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
>> Tristan can get you up to speed with this.
>> 
>> 
>>>> Sanne/Galder/Pete,
>>>> 
>>>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>>> 
>>>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>>>> 
>>>> Brett Meyer
>>>> Software Engineer
>>>> Red Hat, Hibernate ORM
>>>> 
>>> 
>> 
>> 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
> 



From dereed at redhat.com  Fri Dec  6 12:38:08 2013
From: dereed at redhat.com (Dennis Reed)
Date: Fri, 06 Dec 2013 11:38:08 -0600
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
Message-ID: <52A20B80.60601@redhat.com>

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 Cpp clients independently.

Instead of a new intelligence level, if the client told the server what 
features it supports when connecting this could be done more fine-grained,
so that a client could support some subset of functionality (instead of 
being forced to implement the specific extentions in one of the 
pre-defined intelligence levels).

-Dennis

> In one of our discussions, you've also mentioned that you'd want to use the cluster listeners as a foundation for this functionality. That doesn't seem to be the case from the document, or? Not that it's a bad thing, just that I want to clarify the relation between the two. Another way to handle connection management, based on clustered listeners, would be:
> - the node on which the listeners ID hashes is the only one responsible for piggyback notifications to the remote client
> - it creates a cluster listener to be notified on what to send to the client (can make use cluster listener's filtering and transformer capabilities here)
>
> Comparing the two approaches: this approach reuses some code (not sure how much, we might be able to do that anyway) from the cluster listeners and also reduces the number of connections required between clint and server, but at the cost of performance/network hops. Also the number of connections a client is required to have hasn't been a problem yet.
>
> One more note on ST: during ST a node might receive the same notification multiple times (from old owner and new owner). I guess it makes sense documenting that?
>
> On Dec 5, 2013, at 4:16 PM, Galder Zamarre?o <galder at redhat.com> wrote:
>
>> 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 have another read and let the list know what you think of it?
>>
>> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
> +1. Can we include the notification ack in the optionals category?
> What about leaving these as the last bit to be implemented? If time allows (not to delay the release) we can add them, otherwise just add them in future iterations?
>
>
>> Cheers,
>> --
>> Galder Zamarre?o
>> galder at redhat.com
>> twitter.com/galderz
>>
>> Project Lead, Escalante
>> http://escalante.io
>>
>> Engineer, Infinispan
>> http://infinispan.org
>>
> Cheers,


From galder at redhat.com  Mon Dec  9 02:41:45 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Mon, 9 Dec 2013 08:41:45 +0100
Subject: [infinispan-dev] No more pull requests for infinispan-server,
	cachestore-rest and cachestore-leveldb
Message-ID: <069FC6EA-9D84-4EA7-85C2-750C2B4B428C@redhat.com>

Please do not send any more pull requests for these projects while we finalize integration back into infinispan/infinispan of the following projects:

- infinispan/cachestore-leveldb
- infinispan/cachestore-rest
- infinispan/infinispan-server

Any existing pull requests will be integrated or closed.

Cheers,
--
Galder Zamarre?o
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org



From rvansa at redhat.com  Mon Dec  9 03:09:53 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 09 Dec 2013 09:09:53 +0100
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
References: <529F6374.3070901@redhat.com>
	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
Message-ID: <52A57AD1.1040602@redhat.com>

There is one thing I really don't like about the current implementation: 
DefaultCollector. And any other collection that keeps one (or more) 
object per entry.
We can't assume that if you double the number of objects in memory (and 
in fact, if you map entry to bigger object, you do that), they'd still 
fit into it. Moreover, if you map the objects from cache store as well.
I believe we have to use Collector implemented as bounded queue, and 
start reduction phase on the entries that have been mapped in parallel 
to the mapper phase. Otherwise, say hello to OOME.

Cheers

Radim

PS: And don't keep all the futures just to check that all tasks have 
been finished - use ExecutorAllCompletionService instead.

On 12/06/2013 05:18 PM, Mircea Markus wrote:
> Thanks Vladimir, I like the hands on approach!
> Adding -dev, there's a lot of interest around the parallel M/R so I think others will have some thoughts on it as well.
>
> So what you're basically doing in your branch is iterate over all the keys in the cache and then for each key invoke the mapping in a separate thread. Whilst this would work, I think it has some drawbacks:
> - the iteration over the keys in the container happens in sequence, albeit the mapping phases happening in parallel. This speeds things up a bit but not as much as having the iteration
> happening in parallel, especially when the mapper is fast, which I think it's pretty common.
> - the StatelessTask + some smaller objects are being created for each iterated key. That's a lot of noise for the GC imo
>
> I think delegating the parallel iteration to the DataContainer (similar to AdvancedCacheLoader.process (Executor)) would be a better approach IMO:
> - the logic is reusable for other components as well, such as querying (to implement full-scan-like search, or a general purpose parallel iterator over the keys
> - object creation is reduced
> - the DefaultDetaContainer uses an EquivalentConcurrentHashMapV8 for holding the entries, which already supports parallel iteration so the heavy lifting is already in place
>
> On Dec 4, 2013, at 5:16 PM, Vladimir Blagojevic <vblagoje at redhat.com> wrote:
>
>> Here is my M/R parallel execution solution updated to master https://github.com/vblagoje/infinispan/tree/t_2284_new
>>
>> Now, I'll work on your solution which I am starting to like actually the more I think about it. Although I have to admit that I would eviscerate some of your interfaces like these KeyFilters into more prominent packages so we can all use the same interfaces. Also I would see if we can genericize some of your interfaces and implementations.
>>
>> Will keep you updated.
>>
>> Vladimir
> Cheers,


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA


From jedim at vige.it  Mon Dec  9 04:39:55 2013
From: jedim at vige.it (Luca Stancapiano)
Date: Mon, 9 Dec 2013 10:39:55 +0100 (CET)
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <65CD86CD-B6DD-45C6-BC30-79B0523550A4@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
	<2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
	<65CD86CD-B6DD-45C6-BC30-79B0523550A4@redhat.com>
Message-ID: <7da42e414543e2ec9043bdab5166a8c5.squirrel@webmail.register.it>

Hi Randall...... there is a opened issue on infinispan:

https://issues.jboss.org/browse/ISPN-800

It should be ok. It need only a simple test.

> I?d love to see this work proceed for Infinispan, since we want to do the
> same thing for ModeShape, which uses (but does not hide or encapsulate)
> Infinispan.
>
>
> On Dec 6, 2013, at 10:56 AM, Brett Meyer <brmeyer at redhat.com> wrote:
>
>> Sorry, forgot the link:
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-8214
>>
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List"
>> <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>> Sent: Friday, December 6, 2013 11:51:33 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>
>> Randall, that is *definitely* the case and is certainly true for
>> Hibernate.  The work involved:
>>
>> * correctly resolving ClassLoaders based on the activated bundles
>> * supporting multiple containers and contexts (container-managed JPA,
>> un-managed JPA/native, etc.)
>> * fully supporting OSGi/Blueprint services (both for internal services
>> as well as externally-registered)
>> * bundle scanning
>> * generally working towards supporting the dynamic nature
>> * full unit-tests with Arquillian and an OSGi container
>>
>> It's a matter of holistically supporting the "OSGi way" (for better or
>> worse), as opposed to simply ensuring the library's manifest is correct.
>>
>> There were a bloody ton of gotchas and caveats I hit along the way.
>> That's more along the lines of where I might be able to help.
>>
>> I'm even more interested in this effort so that we can support
>> hibernate-infinispan 2nd level caching within ORM.  On the first
>> attempt, I hit  ClassLoader issues [1].  Some of that may already be
>> resolved.
>>
>> The next step may simply be giving hibernate-infinispan another shot and
>> correcting things as I find them.  In parallel, feel free to let me know
>> if there's anything else!  ORM supports lots of OSGi-enabled extension
>> points, etc. that are powerful for users, but obviously I don't have the
>> Infinispan knowledge to know what would be necessary.
>>
>> Thanks!
>>
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Randall Hauch" <rhauch at redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
>> Sent: Friday, December 6, 2013 10:57:23 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>
>> Brett, correct me if I?m wrong, but isn?t there a difference in making
>> some library *work* in an OSGi environment and making that library
>> *naturally fit well* in an OSGi-enabled application? For example, making
>> the JAR?s be OSGi bundles is easy and technically makes it possible to
>> deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC
>> what you really want is a BundleActivator or Declarative Services [1] so
>> that the library?s components are readily available in a naturally-OSGi
>> way.
>>
>> [1]
>> http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>>
>>> + infinispan-dev
>>>
>>> Thanks for offering to look into this Brett!
>>> We're already producing OSGi bundles for our modules, but these are not
>>> tested extensively so if you'd review them and test them a bit would be
>>> great!
>>> Tristan can get you up to speed with this.
>>>
>>>
>>>>> Sanne/Galder/Pete,
>>>>>
>>>>> Random question: what's the current state of making Infinispan OSGi
>>>>> friendly?  I'm definitely interested in helping, if it's still a
>>>>> need.  This past year, I went through the exercise of making
>>>>> Hibernate work well in OSGi, so all of challenges (read: *many* of
>>>>> them) are still fairly fresh on my mind.  Plus, I'd love for
>>>>> hibernate-infinispan to work in OSGi.
>>>>>
>>>>> If you're up for it, fill me in?  I'm happy to pull everything down
>>>>> and start working with it.
>>>>>
>>>>> Brett Meyer
>>>>> Software Engineer
>>>>> Red Hat, Hibernate ORM
>>>>>
>>>>
>>>
>>> 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
>>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>


-- 
Luca Stancapiano
javaee consultant
skype: flashboss62
mobile: +393381584484

From sanne at infinispan.org  Mon Dec  9 06:41:54 2013
From: sanne at infinispan.org (Sanne Grinovero)
Date: Mon, 9 Dec 2013 11:41:54 +0000
Subject: [infinispan-dev] The monthly failing tests newsletter
Message-ID: <CAFm4XO3Gm-4JTDhLEmVbr-gDTv-yFEgP-1uPk9Cy6MPCPaL+jA@mail.gmail.com>

Failed tests:
  ThreadLocalLeakTest.testCheckThreadLocalLeaks:87 IllegalState Thread
locals st...
  ExplicitUnlockTest.testLock:43->doTestLock:80 All worker should
complete without exceptions
  ExplicitUnlockTest.testLockNoExplicitUnlock:51->doTestLock:80 All
worker should complete without exceptions
  ExplicitUnlockTest.testLockNoExplicitUnlockTwoTasks:55->doTestLock:80
All worker should complete without exceptions
  UNORDEREDEvictionFunctionalTest>BaseEvictionFunctionalTest.testSimpleExpirationMaxIdle:54
cache size should be zero: 128
  StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusy:81->thirdWritingCacheTest:119
null

Tests run: 3808, Failures: 6, Errors: 0, Skipped: 0

From vblagoje at redhat.com  Mon Dec  9 10:21:28 2013
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Mon, 09 Dec 2013 10:21:28 -0500
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <52A57AD1.1040602@redhat.com>
References: <529F6374.3070901@redhat.com>	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
	<52A57AD1.1040602@redhat.com>
Message-ID: <52A5DFF8.3080107@redhat.com>

Radim, these are some very good ideas. And I think we should put them on 
the roadmap.

Also, I like your ExecutorAllCompletionService, however, I think it will 
not work in this case as we often do not have exclusive access to the 
underlying executor service used in ExecutorAllCompletionService. There 
might be some other Infinispan part using the same executor service 
which will screw up the logic of incrementing and decrementing tasks. It 
seems like you need to do counting logic based on some id or smth similar.

On 12/9/2013, 3:09 AM, Radim Vansa wrote:
> There is one thing I really don't like about the current implementation:
> DefaultCollector. And any other collection that keeps one (or more)
> object per entry.
> We can't assume that if you double the number of objects in memory (and
> in fact, if you map entry to bigger object, you do that), they'd still
> fit into it. Moreover, if you map the objects from cache store as well.
> I believe we have to use Collector implemented as bounded queue, and
> start reduction phase on the entries that have been mapped in parallel
> to the mapper phase. Otherwise, say hello to OOME.
>
> Cheers
>
> Radim
>
> PS: And don't keep all the futures just to check that all tasks have
> been finished - use ExecutorAllCompletionService instead.
>
>


From rvansa at redhat.com  Mon Dec  9 11:33:31 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 09 Dec 2013 17:33:31 +0100
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <52A5DFF8.3080107@redhat.com>
References: <529F6374.3070901@redhat.com>	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
	<52A57AD1.1040602@redhat.com> <52A5DFF8.3080107@redhat.com>
Message-ID: <52A5F0DB.7090401@redhat.com>

On 12/09/2013 04:21 PM, Vladimir Blagojevic wrote:
> Radim, these are some very good ideas. And I think we should put them on
> the roadmap.
Do you have any JIRA where this could be marked down?
>
> Also, I like your ExecutorAllCompletionService, however, I think it will
> not work in this case as we often do not have exclusive access to the
> underlying executor service used in ExecutorAllCompletionService. There
> might be some other Infinispan part using the same executor service
> which will screw up the logic of incrementing and decrementing tasks. It
> seems like you need to do counting logic based on some id or smth similar.
You're right - I am not really sure which threadpools does M/R use. And 
in fact it might happen that currently multiple executions using the 
persistence executor would interfere. I should fix the service to add 
the ID and multiplex internally! Created [1] for that.
Shouldn't there be separate threadpools for map and reduce tasks? I 
mean, two threadpools, because used mapper pool should not block another 
reduce tasks to be executed (otherwise there might be a deadlock between 
the threadpools and bounded queue in collector).

Radim

[1] https://issues.jboss.org/browse/ISPN-3800
>
> On 12/9/2013, 3:09 AM, Radim Vansa wrote:
>> There is one thing I really don't like about the current implementation:
>> DefaultCollector. And any other collection that keeps one (or more)
>> object per entry.
>> We can't assume that if you double the number of objects in memory (and
>> in fact, if you map entry to bigger object, you do that), they'd still
>> fit into it. Moreover, if you map the objects from cache store as well.
>> I believe we have to use Collector implemented as bounded queue, and
>> start reduction phase on the entries that have been mapped in parallel
>> to the mapper phase. Otherwise, say hello to OOME.
>>
>> Cheers
>>
>> Radim
>>
>> PS: And don't keep all the futures just to check that all tasks have
>> been finished - use ExecutorAllCompletionService instead.
>>
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA


From rvansa at redhat.com  Mon Dec  9 11:38:53 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 09 Dec 2013 17:38:53 +0100
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <52A5F0DB.7090401@redhat.com>
References: <529F6374.3070901@redhat.com>	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
	<52A57AD1.1040602@redhat.com> <52A5DFF8.3080107@redhat.com>
	<52A5F0DB.7090401@redhat.com>
Message-ID: <52A5F21D.1050303@redhat.com>

On 12/09/2013 05:33 PM, Radim Vansa wrote:
> On 12/09/2013 04:21 PM, Vladimir Blagojevic wrote:
>> Radim, these are some very good ideas. And I think we should put them on
>> the roadmap.
> Do you have any JIRA where this could be marked down?
>> Also, I like your ExecutorAllCompletionService, however, I think it will
>> not work in this case as we often do not have exclusive access to the
>> underlying executor service used in ExecutorAllCompletionService. There
>> might be some other Infinispan part using the same executor service
>> which will screw up the logic of incrementing and decrementing tasks. It
>> seems like you need to do counting logic based on some id or smth similar.
> You're right - I am not really sure which threadpools does M/R use. And
> in fact it might happen that currently multiple executions using the
> persistence executor would interfere. I should fix the service to add
> the ID and multiplex internally! Created [1] for that.
Aah, I got confused... Only the executor is shared, the underlying 
ExecutorCompletionService (with the queue of futures) is private to the 
EACS, therefore, it's safe to share the Executor itself.

Radim

> Shouldn't there be separate threadpools for map and reduce tasks? I
> mean, two threadpools, because used mapper pool should not block another
> reduce tasks to be executed (otherwise there might be a deadlock between
> the threadpools and bounded queue in collector).
>
> Radim
>
> [1] https://issues.jboss.org/browse/ISPN-3800
>> On 12/9/2013, 3:09 AM, Radim Vansa wrote:
>>> There is one thing I really don't like about the current implementation:
>>> DefaultCollector. And any other collection that keeps one (or more)
>>> object per entry.
>>> We can't assume that if you double the number of objects in memory (and
>>> in fact, if you map entry to bigger object, you do that), they'd still
>>> fit into it. Moreover, if you map the objects from cache store as well.
>>> I believe we have to use Collector implemented as bounded queue, and
>>> start reduction phase on the entries that have been mapped in parallel
>>> to the mapper phase. Otherwise, say hello to OOME.
>>>
>>> Cheers
>>>
>>> Radim
>>>
>>> PS: And don't keep all the futures just to check that all tasks have
>>> been finished - use ExecutorAllCompletionService instead.
>>>
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA


From mmarkus at redhat.com  Mon Dec  9 12:47:40 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Mon, 9 Dec 2013 17:47:40 +0000
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <52A20B80.60601@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
	<52A20B80.60601@redhat.com>
Message-ID: <D5CECCDB-954C-4290-8B41-474F3186B5FA@redhat.com>

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).
There are some nice advantages of doing this: build the filter and the listener at runtime, in a language independent manner(assuming query DSL is migrated), with an API customers are already used to. 


On Dec 6, 2013, at 5:38 PM, Dennis Reed <dereed at redhat.com> wrote:

> 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 Cpp clients independently.
> 
> Instead of a new intelligence level, if the client told the server what 
> features it supports when connecting this could be done more fine-grained,
> so that a client could support some subset of functionality (instead of 
> being forced to implement the specific extentions in one of the 
> pre-defined intelligence levels).
> 
> -Dennis
> 
>> In one of our discussions, you've also mentioned that you'd want to use the cluster listeners as a foundation for this functionality. That doesn't seem to be the case from the document, or? Not that it's a bad thing, just that I want to clarify the relation between the two. Another way to handle connection management, based on clustered listeners, would be:
>> - the node on which the listeners ID hashes is the only one responsible for piggyback notifications to the remote client
>> - it creates a cluster listener to be notified on what to send to the client (can make use cluster listener's filtering and transformer capabilities here)
>> 
>> Comparing the two approaches: this approach reuses some code (not sure how much, we might be able to do that anyway) from the cluster listeners and also reduces the number of connections required between clint and server, but at the cost of performance/network hops. Also the number of connections a client is required to have hasn't been a problem yet.
>> 
>> One more note on ST: during ST a node might receive the same notification multiple times (from old owner and new owner). I guess it makes sense documenting that?
>> 
>> On Dec 5, 2013, at 4:16 PM, Galder Zamarre?o <galder at redhat.com> wrote:
>> 
>>> 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 have another read and let the list know what you think of it?
>>> 
>>> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
>> +1. Can we include the notification ack in the optionals category?
>> What about leaving these as the last bit to be implemented? If time allows (not to delay the release) we can add them, otherwise just add them in future iterations?
>> 
>> 
>>> Cheers,
>>> --
>>> Galder Zamarre?o
>>> galder at redhat.com
>>> twitter.com/galderz
>>> 
>>> Project Lead, Escalante
>>> http://escalante.io
>>> 
>>> Engineer, Infinispan
>>> http://infinispan.org
>>> 
>> Cheers,
> 
> _______________________________________________
> 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)






From mlinhard at redhat.com  Tue Dec 10 07:46:46 2013
From: mlinhard at redhat.com (Michal Linhard)
Date: Tue, 10 Dec 2013 13:46:46 +0100
Subject: [infinispan-dev] Hot rod version 1.3 and QueryOperation
Message-ID: <52A70D36.8070901@redhat.com>

Hi,

I'm checking the JDG 6.2.0 Docs on Hot Rod protocol that should describe 
the 1.3 version

I realized that we don't actually fill version number 13 yet, i.e. 
there's no such thing as HotRodConstants.VERSION_13 yet
but we already added HotRodConstants.QUERY_REQUEST = 0x1F; to protocol 
1.2 which is in contradiction with docs
that says queries come in version 1.3: 
http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_hot_rod_protocol

how do we plan to solve this ?
is this a bug and are we going to create version 13, whereby query op 
will be supported only there and not in 12 ?

m.

-- 
Michal Linhard
Quality Assurance Engineer
JBoss Datagrid

Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 8262320
mobile: +420 728 626 363


From rvansa at redhat.com  Tue Dec 10 13:17:22 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Tue, 10 Dec 2013 19:17:22 +0100
Subject: [infinispan-dev] Denormalizing hashes
Message-ID: <52A75AB2.6040500@redhat.com>

Hi Galder,

as I am trying to debug some problem in C++ client, I was looking into 
the server code. And I am not sure whether I understand the code 
correctly, but it seems to me that the server denormalizes the 
consistent hash for each client anew (after each topology change or 
client joining). Is this true? Looking into trace logs, I can see stuff 
like

18:15:17,339 TRACE [org.infinispan.server.hotrod.Encoders$Encoder12$] 
(HotRodServerWorker-12) Writing hash id 639767 for 192.168.11.101:11222

 From denormalizeSegmentHashIds() method I see that this means that we 
have executed the hash function 639768 times just to notify one client. 
Is my understanding correct?

Also, there is nothing like the concept of primary owner, is this right? 
I thought that every first request in HotRod will go to primary owner, 
so that the PUT does not have to do the first hop and is executed 
directly on the primary. But it seems to me that it goes to any of the 
owners (practically random one, as you are only looking for the numOwner 
ids in leeway = on the beginning of the range - then, 99.98% or more 
requests should go to the server with last position in the leeway). This 
looks pretty suboptimal for writes, isn't it?

Cheers

Radim

PS: for every line of code you write in Scala, God kills a kitten

-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA


From dan.berindei at gmail.com  Wed Dec 11 03:18:58 2013
From: dan.berindei at gmail.com (Dan Berindei)
Date: Wed, 11 Dec 2013 10:18:58 +0200
Subject: [infinispan-dev] Denormalizing hashes
In-Reply-To: <52A75AB2.6040500@redhat.com>
References: <52A75AB2.6040500@redhat.com>
Message-ID: <CA+nfvwTPW0wEGccgbyKhV4Wa_JhRVfOV8khP98smy4FNGNdhjg@mail.gmail.com>

Hi Radim

Actually, it's me that wrote the denormalization code :)

It was meant as a stop-gap measure before we upgraded the HotRod protocol
to support the segment-based consistent hash, but the denormalization
worked well enough (or so we thought) that we didn't get to changing the
protocol yet.

That's not a big change in itself, but we also wanted to make the
consistent hash per-cache on the client (it's now per-cache manager), and
that's a bit more complicated to do. And it's not like it would have been a
good idea to change this before starting the C++ client, the client would
still have to support the current style of consistent hash.


On Tue, Dec 10, 2013 at 8:17 PM, Radim Vansa <rvansa at redhat.com> wrote:

> Hi Galder,
>
> as I am trying to debug some problem in C++ client, I was looking into
> the server code. And I am not sure whether I understand the code
> correctly, but it seems to me that the server denormalizes the
> consistent hash for each client anew (after each topology change or
> client joining). Is this true? Looking into trace logs, I can see stuff
> like
>
> 18:15:17,339 TRACE [org.infinispan.server.hotrod.Encoders$Encoder12$]
> (HotRodServerWorker-12) Writing hash id 639767 for 192.168.11.101:11222
>
>  From denormalizeSegmentHashIds() method I see that this means that we
> have executed the hash function 639768 times just to notify one client.
> Is my understanding correct?
>

Yes, this happens every time a client joins and/or every time the cache
topology changes.

We could easily cache the result of denormalizeSegmentHashIds, as it only
depends on the number of segments. It's just that I wasn't expecting it to
take so many iterations.



>
> Also, there is nothing like the concept of primary owner, is this right?
>

The client CH doesn't have a concept of backup owners. But for each (hash
id, server) pair that gets sent to the client, it means all the hash codes
between the previous hash id and this hash id have this server as the
primary owner. The server in the next (hash id, server) pair is the first
backup, and so on.

For each segment, the server generates numOwners (hash id, server) pairs.
That means, for most of the hash codes in the segment, the list of owners
on the client will be the same as the list of owners on the server. But for
0.0002 (leewayFraction) of the hash codes, the client primary owner will be
indeed one of the server backup owners.



> I thought that every first request in HotRod will go to primary owner,
> so that the PUT does not have to do the first hop and is executed
> directly on the primary. But it seems to me that it goes to any of the
> owners (practically random one, as you are only looking for the numOwner
> ids in leeway = on the beginning of the range - then, 99.98% or more
> requests should go to the server with last position in the leeway). This
> looks pretty suboptimal for writes, isn't it?
>

I'm not sure what you mean here, but I'm pretty sure the request goes to
the correct server because we have a test for it:
ConsistentHashV1IntegrationTest

Cheers
Dan



>
> Cheers
>
> Radim
>
> PS: for every line of code you write in Scala, God kills a kitten
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
>
> _______________________________________________
> 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/20131211/31e75448/attachment-0001.html 

From rvansa at redhat.com  Wed Dec 11 03:38:04 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 11 Dec 2013 09:38:04 +0100
Subject: [infinispan-dev] Denormalizing hashes
In-Reply-To: <CA+nfvwTPW0wEGccgbyKhV4Wa_JhRVfOV8khP98smy4FNGNdhjg@mail.gmail.com>
References: <52A75AB2.6040500@redhat.com>
	<CA+nfvwTPW0wEGccgbyKhV4Wa_JhRVfOV8khP98smy4FNGNdhjg@mail.gmail.com>
Message-ID: <52A8246C.7000507@redhat.com>

Hi Dan

I am not speaking about changing something for the C++ client, I 
understand that the client code cannot be changed in order to keep the 
backward compatibility.

The current hash-wheel approach is working well, but there are few flaws 
that could be fixed keeping the client code untouched. Please, correct 
me if I am wrong.

1) The denormalization is executed for every client for every topology 
change/client join. I don't have any numbers, but calling the hashing 
algorithm million times per every such occasion sounds as wasting 
computing power. -> cache the denormalized stuff on server

2) The server is sending numOwners hashIds per segment, one for each 
owner. What's the reason for that? I think that only primary owners 
should be inserted there. This would:
a) target all PUT requests to primary owner, reducing PUT latency and 
lowering the general load in cluster
b) reduce the routing information

And yes, ISPN-3530 and ISPN-3701 are pretty serious, but IMO rather 
orthogonal to the segment vs. hash wheel approach and its details.

Radim


On 12/11/2013 09:18 AM, Dan Berindei wrote:
> Hi Radim
>
> Actually, it's me that wrote the denormalization code :)
>
> It was meant as a stop-gap measure before we upgraded the HotRod 
> protocol to support the segment-based consistent hash, but the 
> denormalization worked well enough (or so we thought) that we didn't 
> get to changing the protocol yet.
>
> That's not a big change in itself, but we also wanted to make the 
> consistent hash per-cache on the client (it's now per-cache manager), 
> and that's a bit more complicated to do. And it's not like it would 
> have been a good idea to change this before starting the C++ client, 
> the client would still have to support the current style of consistent 
> hash.
>
>
> On Tue, Dec 10, 2013 at 8:17 PM, Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     Hi Galder,
>
>     as I am trying to debug some problem in C++ client, I was looking into
>     the server code. And I am not sure whether I understand the code
>     correctly, but it seems to me that the server denormalizes the
>     consistent hash for each client anew (after each topology change or
>     client joining). Is this true? Looking into trace logs, I can see
>     stuff
>     like
>
>     18:15:17,339 TRACE [org.infinispan.server.hotrod.Encoders$Encoder12$]
>     (HotRodServerWorker-12) Writing hash id 639767 for
>     192.168.11.101:11222 <http://192.168.11.101:11222>
>
>      From denormalizeSegmentHashIds() method I see that this means that we
>     have executed the hash function 639768 times just to notify one
>     client.
>     Is my understanding correct?
>
>
> Yes, this happens every time a client joins and/or every time the 
> cache topology changes.
>
> We could easily cache the result of denormalizeSegmentHashIds, as it 
> only depends on the number of segments. It's just that I wasn't 
> expecting it to take so many iterations.
>
>
>     Also, there is nothing like the concept of primary owner, is this
>     right?
>
>
> The client CH doesn't have a concept of backup owners. But for each 
> (hash id, server) pair that gets sent to the client, it means all the 
> hash codes between the previous hash id and this hash id have this 
> server as the primary owner. The server in the next (hash id, server) 
> pair is the first backup, and so on.
>
> For each segment, the server generates numOwners (hash id, server) 
> pairs. That means, for most of the hash codes in the segment, the list 
> of owners on the client will be the same as the list of owners on the 
> server. But for 0.0002 (leewayFraction) of the hash codes, the client 
> primary owner will be indeed one of the server backup owners.
>
>
>     I thought that every first request in HotRod will go to primary owner,
>     so that the PUT does not have to do the first hop and is executed
>     directly on the primary. But it seems to me that it goes to any of the
>     owners (practically random one, as you are only looking for the
>     numOwner
>     ids in leeway = on the beginning of the range - then, 99.98% or more
>     requests should go to the server with last position in the
>     leeway). This
>     looks pretty suboptimal for writes, isn't it?
>
>
> I'm not sure what you mean here, but I'm pretty sure the request goes 
> to the correct server because we have a test for it: 
> ConsistentHashV1IntegrationTest
>
> Cheers
> Dan
>
>
>     Cheers
>
>     Radim
>
>     PS: for every line of code you write in Scala, God kills a kitten
>
>     --
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss DataGrid QA
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131211/f2990197/attachment.html 

From dan.berindei at gmail.com  Wed Dec 11 04:01:23 2013
From: dan.berindei at gmail.com (Dan Berindei)
Date: Wed, 11 Dec 2013 11:01:23 +0200
Subject: [infinispan-dev] Denormalizing hashes
In-Reply-To: <52A8246C.7000507@redhat.com>
References: <52A75AB2.6040500@redhat.com>
	<CA+nfvwTPW0wEGccgbyKhV4Wa_JhRVfOV8khP98smy4FNGNdhjg@mail.gmail.com>
	<52A8246C.7000507@redhat.com>
Message-ID: <CA+nfvwQMohu7BsHVKriK4qVMRAgYbny3S0Pz-8HRx_4zv0WeKg@mail.gmail.com>

On Wed, Dec 11, 2013 at 10:38 AM, Radim Vansa <rvansa at redhat.com> wrote:

>  Hi Dan
>
> I am not speaking about changing something for the C++ client, I
> understand that the client code cannot be changed in order to keep the
> backward compatibility.
>

Sure, I was just trying to give some background information on what we
discussed and why we still have the wheel-based CH in the client.


>
> The current hash-wheel approach is working well, but there are few flaws
> that could be fixed keeping the client code untouched. Please, correct me
> if I am wrong.
>
> 1) The denormalization is executed for every client for every topology
> change/client join. I don't have any numbers, but calling the hashing
> algorithm million times per every such occasion sounds as wasting computing
> power. -> cache the denormalized stuff on server
>

+1, like I said it would be easy to do but it never came up as a problem
before.



>
> 2) The server is sending numOwners hashIds per segment, one for each
> owner. What's the reason for that? I think that only primary owners should
> be inserted there. This would:
>

The main reason is to support clients from Infinispan 5.1, which pick a
random owner instead of always choosing the primary (
https://issues.jboss.org/browse/ISPN-2655).



> a) target all PUT requests to primary owner, reducing PUT latency and
> lowering the general load in cluster
>

Nope, it wouldn't. The same fraction of requests would go to the primary
owner as before, because we won't find the exact "denormalized" hash id
that maps to the segment border when normalized.


b) reduce the routing information
>

For 7.0, I guess we could say that 5.1 clients are no longer supported and
we could switch to sending only the primary owners to the clients. But I'm
not sure whether the loss of backwards compatibility is worth a couple
hundred bytes sent once for every client.



> And yes, ISPN-3530 and ISPN-3701 are pretty serious, but IMO rather
> orthogonal to the segment vs. hash wheel approach and its details.
>
>
Agree. Could you create issues in JIRA for both your proposals?



>  Radim
>
>
>
> On 12/11/2013 09:18 AM, Dan Berindei wrote:
>
>  Hi Radim
>
>  Actually, it's me that wrote the denormalization code :)
>
>  It was meant as a stop-gap measure before we upgraded the HotRod protocol
> to support the segment-based consistent hash, but the denormalization
> worked well enough (or so we thought) that we didn't get to changing the
> protocol yet.
>
> That's not a big change in itself, but we also wanted to make the
> consistent hash per-cache on the client (it's now per-cache manager), and
> that's a bit more complicated to do. And it's not like it would have been a
> good idea to change this before starting the C++ client, the client would
> still have to support the current style of consistent hash.
>
>
> On Tue, Dec 10, 2013 at 8:17 PM, Radim Vansa <rvansa at redhat.com> wrote:
>
>> Hi Galder,
>>
>> as I am trying to debug some problem in C++ client, I was looking into
>> the server code. And I am not sure whether I understand the code
>> correctly, but it seems to me that the server denormalizes the
>> consistent hash for each client anew (after each topology change or
>> client joining). Is this true? Looking into trace logs, I can see stuff
>> like
>>
>> 18:15:17,339 TRACE [org.infinispan.server.hotrod.Encoders$Encoder12$]
>> (HotRodServerWorker-12) Writing hash id 639767 for 192.168.11.101:11222
>>
>>  From denormalizeSegmentHashIds() method I see that this means that we
>> have executed the hash function 639768 times just to notify one client.
>> Is my understanding correct?
>>
>
>  Yes, this happens every time a client joins and/or every time the cache
> topology changes.
>
> We could easily cache the result of denormalizeSegmentHashIds, as it only
> depends on the number of segments. It's just that I wasn't expecting it to
> take so many iterations.
>
>
>
>>
>> Also, there is nothing like the concept of primary owner, is this right?
>>
>
>  The client CH doesn't have a concept of backup owners. But for each
> (hash id, server) pair that gets sent to the client, it means all the hash
> codes between the previous hash id and this hash id have this server as the
> primary owner. The server in the next (hash id, server) pair is the first
> backup, and so on.
>
>  For each segment, the server generates numOwners (hash id, server)
> pairs. That means, for most of the hash codes in the segment, the list of
> owners on the client will be the same as the list of owners on the server.
> But for 0.0002 (leewayFraction) of the hash codes, the client primary owner
> will be indeed one of the server backup owners.
>
>
>
>> I thought that every first request in HotRod will go to primary owner,
>> so that the PUT does not have to do the first hop and is executed
>> directly on the primary. But it seems to me that it goes to any of the
>> owners (practically random one, as you are only looking for the numOwner
>> ids in leeway = on the beginning of the range - then, 99.98% or more
>> requests should go to the server with last position in the leeway). This
>> looks pretty suboptimal for writes, isn't it?
>>
>
>  I'm not sure what you mean here, but I'm pretty sure the request goes to
> the correct server because we have a test for it:
> ConsistentHashV1IntegrationTest
>
>  Cheers
>  Dan
>
>
>
>>
>> Cheers
>>
>> Radim
>>
>> PS: for every line of code you write in Scala, God kills a kitten
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss DataGrid QA
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
>
> _______________________________________________
> infinispan-dev mailing listinfinispan-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> --
> Radim Vansa <rvansa at redhat.com> <rvansa at redhat.com>
> JBoss DataGrid QA
>
>
> _______________________________________________
> 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/20131211/a115deb8/attachment-0001.html 

From rvansa at redhat.com  Wed Dec 11 04:37:36 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 11 Dec 2013 10:37:36 +0100
Subject: [infinispan-dev] Denormalizing hashes
In-Reply-To: <CA+nfvwQMohu7BsHVKriK4qVMRAgYbny3S0Pz-8HRx_4zv0WeKg@mail.gmail.com>
References: <52A75AB2.6040500@redhat.com>
	<CA+nfvwTPW0wEGccgbyKhV4Wa_JhRVfOV8khP98smy4FNGNdhjg@mail.gmail.com>
	<52A8246C.7000507@redhat.com>
	<CA+nfvwQMohu7BsHVKriK4qVMRAgYbny3S0Pz-8HRx_4zv0WeKg@mail.gmail.com>
Message-ID: <52A83260.8040504@redhat.com>


>
> On Wed, Dec 11, 2013 at 10:38 AM, Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     Hi Dan
>
>     I am not speaking about changing something for the C++ client, I
>     understand that the client code cannot be changed in order to keep
>     the backward compatibility.
>
>
> Sure, I was just trying to give some background information on what we 
> discussed and why we still have the wheel-based CH in the client.
>
>
>     The current hash-wheel approach is working well, but there are few
>     flaws that could be fixed keeping the client code untouched.
>     Please, correct me if I am wrong.
>
>     1) The denormalization is executed for every client for every
>     topology change/client join. I don't have any numbers, but calling
>     the hashing algorithm million times per every such occasion sounds
>     as wasting computing power. -> cache the denormalized stuff on server
>
>
> +1, like I said it would be easy to do but it never came up as a 
> problem before.
>
Fair enough.
>
>
>     2) The server is sending numOwners hashIds per segment, one for
>     each owner. What's the reason for that? I think that only primary
>     owners should be inserted there. This would:
>
>
> The main reason is to support clients from Infinispan 5.1, which pick 
> a random owner instead of always choosing the primary 
> (https://issues.jboss.org/browse/ISPN-2655).

You can always report numKeyOwners=1 and the old code should handle that.

>
>     a) target all PUT requests to primary owner, reducing PUT latency
>     and lowering the general load in cluster
>
>
> Nope, it wouldn't. The same fraction of requests would go to the 
> primary owner as before, because we won't find the exact 
> "denormalized" hash id that maps to the segment border when normalized.

Oh, only now have I noticed that the hashIds are sorted by the 
normalized ID, therefore, the primary owner always picks the first 
position (and most requests will hit the first). Mea culpa. Still, it 
makes no sense to include the backup owners into the routing table, as 
the probability that a read will hit them is negligable.

>
>     b) reduce the routing information
>
>
> For 7.0, I guess we could say that 5.1 clients are no longer supported 
> and we could switch to sending only the primary owners to the clients. 
> But I'm not sure whether the loss of backwards compatibility is worth 
> a couple hundred bytes sent once for every client.
>
>
>
>     And yes, ISPN-3530 and ISPN-3701 are pretty serious, but IMO
>     rather orthogonal to the segment vs. hash wheel approach and its
>     details.
>
>
> Agree. Could you create issues in JIRA for both your proposals?

OK. By the way, shouldn't we tag the features that should be included 
for hotrod protocol v1.4 with some tag, such as hotrod14?
But as I said, if we fake the numOwners to be always 1, it should be 
backwards compatible even now.
Nevertheless, as you in fact do route most requests to the primary 
owner, it won't provide much performance gain and it's not as hot as I 
first thought.

Radim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131211/9c5ef3c0/attachment.html 

From dan.berindei at gmail.com  Wed Dec 11 05:37:28 2013
From: dan.berindei at gmail.com (Dan Berindei)
Date: Wed, 11 Dec 2013 12:37:28 +0200
Subject: [infinispan-dev] Denormalizing hashes
In-Reply-To: <52A83260.8040504@redhat.com>
References: <52A75AB2.6040500@redhat.com>
	<CA+nfvwTPW0wEGccgbyKhV4Wa_JhRVfOV8khP98smy4FNGNdhjg@mail.gmail.com>
	<52A8246C.7000507@redhat.com>
	<CA+nfvwQMohu7BsHVKriK4qVMRAgYbny3S0Pz-8HRx_4zv0WeKg@mail.gmail.com>
	<52A83260.8040504@redhat.com>
Message-ID: <CA+nfvwQLOx5eVRX2=tbxw06TNkZQmdY4hDzNJzeRGMc7CBmCPw@mail.gmail.com>

On Wed, Dec 11, 2013 at 11:37 AM, Radim Vansa <rvansa at redhat.com> wrote:

>
>
> On Wed, Dec 11, 2013 at 10:38 AM, Radim Vansa <rvansa at redhat.com> wrote:
>
>>  Hi Dan
>>
>> I am not speaking about changing something for the C++ client, I
>> understand that the client code cannot be changed in order to keep the
>> backward compatibility.
>>
>
>  Sure, I was just trying to give some background information on what we
> discussed and why we still have the wheel-based CH in the client.
>
>
>>
>> The current hash-wheel approach is working well, but there are few flaws
>> that could be fixed keeping the client code untouched. Please, correct me
>> if I am wrong.
>>
>> 1) The denormalization is executed for every client for every topology
>> change/client join. I don't have any numbers, but calling the hashing
>> algorithm million times per every such occasion sounds as wasting computing
>> power. -> cache the denormalized stuff on server
>>
>
>  +1, like I said it would be easy to do but it never came up as a problem
> before.
>
>    Fair enough.
>
>
>
>>
>> 2) The server is sending numOwners hashIds per segment, one for each
>> owner. What's the reason for that? I think that only primary owners should
>> be inserted there. This would:
>>
>
>  The main reason is to support clients from Infinispan 5.1, which pick a
> random owner instead of always choosing the primary (
> https://issues.jboss.org/browse/ISPN-2655).
>
>
> You can always report numKeyOwners=1 and the old code should handle that.
>

Yeah, it looks like it would work. I was thinking that when retrying a
failed operation, the pre-5.2 client would still try one of the key owners,
but I see now that it always chose a random server when retrying. Also, the
client doesn't expose numKeyOwners to the user, like I had assumed.


>
>
>
>
>>  a) target all PUT requests to primary owner, reducing PUT latency and
>> lowering the general load in cluster
>>
>
>  Nope, it wouldn't. The same fraction of requests would go to the primary
> owner as before, because we won't find the exact "denormalized" hash id
> that maps to the segment border when normalized.
>
>
> Oh, only now have I noticed that the hashIds are sorted by the normalized
> ID, therefore, the primary owner always picks the first position (and most
> requests will hit the first). Mea culpa. Still, it makes no sense to
> include the backup owners into the routing table, as the probability that a
> read will hit them is negligable.
>
>
>
>   b) reduce the routing information
>>
>
>  For 7.0, I guess we could say that 5.1 clients are no longer supported
> and we could switch to sending only the primary owners to the clients. But
> I'm not sure whether the loss of backwards compatibility is worth a couple
> hundred bytes sent once for every client.
>
>
>
>> And yes, ISPN-3530 and ISPN-3701 are pretty serious, but IMO rather
>> orthogonal to the segment vs. hash wheel approach and its details.
>>
>>
>  Agree. Could you create issues in JIRA for both your proposals?
>
>
> OK. By the way, shouldn't we tag the features that should be included for
> hotrod protocol v1.4 with some tag, such as hotrod14?
> But as I said, if we fake the numOwners to be always 1, it should be
> backwards compatible even now.
> Nevertheless, as you in fact do route most requests to the primary owner,
> it won't provide much performance gain and it's not as hot as I first
> thought.
>
> Radim
>
>
> _______________________________________________
> 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/20131211/d79fb7e8/attachment.html 

From sanne at infinispan.org  Wed Dec 11 07:32:06 2013
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 11 Dec 2013 12:32:06 +0000
Subject: [infinispan-dev] manual eviction and indexing
Message-ID: <CAFm4XO0b_47dJwW1jLfzo1noYW8NpE=Rzrpy8KxBgJ1mE+xUxg@mail.gmail.com>

Hi Adrian,
+1 good catch.

but what's a realistic use case for {indexing + eviction + no cachestore} ?
I guess some use cases might exist but I don't think it's critical,
would you agree?

and what about automatic eviction?

I think the guiding principle should be that if an entry can be
retrieved by key it should be searchable, and vice-versa, if I can
find it by running a query I should be able to load the result.
So expiry and other forms of eviction should also be considered, but
if there is no practical use case we can consider making this an
illegal configuration or simply log a warning about the particular
configuration.

Sanne

----- Original Message -----
> Hi Sanne,
>
> I found that manual eviction does not update the index. I think manual
> eviction should behave like a remove, if there are no cache stores
> configured.
>
> Here's a test and a 'fix' :)
> https://github.com/anistor/infinispan/tree/t_manual_evict_and_indexing
>
> Let's discuss this when you have time.
>
> There is also the more complex situation of in-DataContainer eviction ...
>

From anistor at redhat.com  Wed Dec 11 10:08:57 2013
From: anistor at redhat.com (Adrian Nistor)
Date: Wed, 11 Dec 2013 17:08:57 +0200
Subject: [infinispan-dev] manual eviction and indexing
In-Reply-To: <CAFm4XO0b_47dJwW1jLfzo1noYW8NpE=Rzrpy8KxBgJ1mE+xUxg@mail.gmail.com>
References: <CAFm4XO0b_47dJwW1jLfzo1noYW8NpE=Rzrpy8KxBgJ1mE+xUxg@mail.gmail.com>
Message-ID: <52A88009.40108@redhat.com>

I Agree. If  indexing + (automatic) eviction + no cachestore is 
currently allowed, then we should add a jira to add this config validation.

But what about manual eviction? Would it make sense to handle it the way 
I did?

On 12/11/2013 02:32 PM, Sanne Grinovero wrote:
> Hi Adrian,
> +1 good catch.
>
> but what's a realistic use case for {indexing + eviction + no cachestore} ?
> I guess some use cases might exist but I don't think it's critical,
> would you agree?
>
> and what about automatic eviction?
>
> I think the guiding principle should be that if an entry can be
> retrieved by key it should be searchable, and vice-versa, if I can
> find it by running a query I should be able to load the result.
> So expiry and other forms of eviction should also be considered, but
> if there is no practical use case we can consider making this an
> illegal configuration or simply log a warning about the particular
> configuration.
>
> Sanne
>
> ----- Original Message -----
>> Hi Sanne,
>>
>> I found that manual eviction does not update the index. I think manual
>> eviction should behave like a remove, if there are no cache stores
>> configured.
>>
>> Here's a test and a 'fix' :)
>> https://github.com/anistor/infinispan/tree/t_manual_evict_and_indexing
>>
>> Let's discuss this when you have time.
>>
>> There is also the more complex situation of in-DataContainer eviction ...
>>


From pedro at infinispan.org  Wed Dec 11 17:47:01 2013
From: pedro at infinispan.org (Pedro Ruivo)
Date: Wed, 11 Dec 2013 22:47:01 +0000
Subject: [infinispan-dev] Clean ThreadLocals
Message-ID: <52A8EB65.4060800@infinispan.org>

Hi,

I've created a method to clean a specific ThreadLocal variable from all 
live threads [1].

My goal is to clean the ThreadLocal variables after a cache stops. It's 
kind expensive method (it uses reflection) but I think it is fine.

Currently, I'm using it to clear the Marshaller ThreadLocal in here [2].

Does anyone see any problem with this approach? Maybe it can be used in 
other possible leaking ThreadLocals?

Cheers,
Pedro

[1] 
https://github.com/infinispan/infinispan/pull/2275/files#diff-212dc0b4165cfee5f764904e5613732fR49
[2] 
https://github.com/infinispan/infinispan/pull/2275/files#diff-dd0f48af603a174d9143f2bf7f1d5c56R189


From david.lloyd at redhat.com  Wed Dec 11 17:52:41 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 11 Dec 2013 16:52:41 -0600
Subject: [infinispan-dev] Clean ThreadLocals
In-Reply-To: <52A8EB65.4060800@infinispan.org>
References: <52A8EB65.4060800@infinispan.org>
Message-ID: <52A8ECB9.9000904@redhat.com>

On 12/11/2013 04:47 PM, Pedro Ruivo wrote:
> Hi,
>
> I've created a method to clean a specific ThreadLocal variable from all
> live threads [1].
>
> My goal is to clean the ThreadLocal variables after a cache stops. It's
> kind expensive method (it uses reflection) but I think it is fine.
>
> Currently, I'm using it to clear the Marshaller ThreadLocal in here [2].
>
> Does anyone see any problem with this approach? Maybe it can be used in
> other possible leaking ThreadLocals?

It's an interesting idea (I've done something similar in the past to 
simply drop all thread locals).  I would recommend that you check that 
all the JDKs you want to support use the same technique for thread 
locals though.  Because these fields are not part of the JDK, they may 
not always exist in all environments.

Also, it is important to only ever clean the thread locals of your 
current thread, or you're inviting all kinds of bizarre concurrency 
problems (maybe even locking threads into infinite loops), especially if 
the thread is running and actively using thread locals at the time.
-- 
- DML

From dan.berindei at gmail.com  Thu Dec 12 04:01:05 2013
From: dan.berindei at gmail.com (Dan Berindei)
Date: Thu, 12 Dec 2013 11:01:05 +0200
Subject: [infinispan-dev] Clean ThreadLocals
In-Reply-To: <52A8ECB9.9000904@redhat.com>
References: <52A8EB65.4060800@infinispan.org> <52A8ECB9.9000904@redhat.com>
Message-ID: <CA+nfvwRZSF17xMnZzQ5TKhYO3Jjd-kDgN8tjhVXbPHyw-iCo5g@mail.gmail.com>

On Thu, Dec 12, 2013 at 12:52 AM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> On 12/11/2013 04:47 PM, Pedro Ruivo wrote:
> > Hi,
> >
> > I've created a method to clean a specific ThreadLocal variable from all
> > live threads [1].
> >
> > My goal is to clean the ThreadLocal variables after a cache stops. It's
> > kind expensive method (it uses reflection) but I think it is fine.
> >
> > Currently, I'm using it to clear the Marshaller ThreadLocal in here [2].
> >
> > Does anyone see any problem with this approach? Maybe it can be used in
> > other possible leaking ThreadLocals?
>
> It's an interesting idea (I've done something similar in the past to
> simply drop all thread locals).  I would recommend that you check that
> all the JDKs you want to support use the same technique for thread
> locals though.  Because these fields are not part of the JDK, they may
> not always exist in all environments.
>

Yeah, the implementation of ThreadLocal has changed in the past and is
likely to change again in the future. If that happens and we have to
support different JDKs with different methods for clearing ThreadLocals, it
won't be pretty.


> Also, it is important to only ever clean the thread locals of your
> current thread, or you're inviting all kinds of bizarre concurrency
> problems (maybe even locking threads into infinite loops), especially if
> the thread is running and actively using thread locals at the time.
>

Indeed, ThreadLocalMap doesn't look to be thread-safe. I'm not sure if a
remote() from another thread can cause an infinite loop like in HashMap
because it uses open addressing instead of chaining, but it looks like it
may cause a get() for a different ThreadLocal to return the wrong instance.
(I would be ok with it if it would only cause breakage for threads using
the cache that's being stopped, but it looks like it can touch more than
one entry.)

I think we shouldn't concern ourselves with actually removing the
ThreadLocal from the map, we just have to keep track of the ThreadLocal
instances and clean any references to other objects they might have (a la
ExternalizerTableProxy). Or maybe give up on ThreadLocals and use a
ConcurrentWeakKeyHashMap<Thread, PerThreadInstanceHolder> instead.

Dan



> --
> - DML
> _______________________________________________
> 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/20131212/d2260aa7/attachment.html 

From sanne at infinispan.org  Thu Dec 12 05:35:44 2013
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 12 Dec 2013 10:35:44 +0000
Subject: [infinispan-dev] Clean ThreadLocals
In-Reply-To: <CA+nfvwRZSF17xMnZzQ5TKhYO3Jjd-kDgN8tjhVXbPHyw-iCo5g@mail.gmail.com>
References: <52A8EB65.4060800@infinispan.org> <52A8ECB9.9000904@redhat.com>
	<CA+nfvwRZSF17xMnZzQ5TKhYO3Jjd-kDgN8tjhVXbPHyw-iCo5g@mail.gmail.com>
Message-ID: <CAFm4XO1SJrZHRbGSM4H-rH7B5nfnE=-gCUc9_o3EnOFY+3aC6w@mail.gmail.com>

It all looks so much more complex than getting rid of this ThreadLocal?

On 12 December 2013 09:01, Dan Berindei <dan.berindei at gmail.com> wrote:
>
>
>
> On Thu, Dec 12, 2013 at 12:52 AM, David M. Lloyd <david.lloyd at redhat.com>
> wrote:
>>
>> On 12/11/2013 04:47 PM, Pedro Ruivo wrote:
>> > Hi,
>> >
>> > I've created a method to clean a specific ThreadLocal variable from all
>> > live threads [1].
>> >
>> > My goal is to clean the ThreadLocal variables after a cache stops. It's
>> > kind expensive method (it uses reflection) but I think it is fine.
>> >
>> > Currently, I'm using it to clear the Marshaller ThreadLocal in here [2].
>> >
>> > Does anyone see any problem with this approach? Maybe it can be used in
>> > other possible leaking ThreadLocals?
>>
>> It's an interesting idea (I've done something similar in the past to
>> simply drop all thread locals).  I would recommend that you check that
>> all the JDKs you want to support use the same technique for thread
>> locals though.  Because these fields are not part of the JDK, they may
>> not always exist in all environments.
>
>
> Yeah, the implementation of ThreadLocal has changed in the past and is
> likely to change again in the future. If that happens and we have to support
> different JDKs with different methods for clearing ThreadLocals, it won't be
> pretty.
>
>>
>> Also, it is important to only ever clean the thread locals of your
>> current thread, or you're inviting all kinds of bizarre concurrency
>> problems (maybe even locking threads into infinite loops), especially if
>> the thread is running and actively using thread locals at the time.
>
>
> Indeed, ThreadLocalMap doesn't look to be thread-safe. I'm not sure if a
> remote() from another thread can cause an infinite loop like in HashMap
> because it uses open addressing instead of chaining, but it looks like it
> may cause a get() for a different ThreadLocal to return the wrong instance.
> (I would be ok with it if it would only cause breakage for threads using the
> cache that's being stopped, but it looks like it can touch more than one
> entry.)
>
> I think we shouldn't concern ourselves with actually removing the
> ThreadLocal from the map, we just have to keep track of the ThreadLocal
> instances and clean any references to other objects they might have (a la
> ExternalizerTableProxy). Or maybe give up on ThreadLocals and use a
> ConcurrentWeakKeyHashMap<Thread, PerThreadInstanceHolder> instead.
>
> Dan
>
>
>>
>> --
>> - DML
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From pedro at infinispan.org  Thu Dec 12 06:02:35 2013
From: pedro at infinispan.org (Pedro Ruivo)
Date: Thu, 12 Dec 2013 11:02:35 +0000
Subject: [infinispan-dev] Clean ThreadLocals
In-Reply-To: <CAFm4XO1SJrZHRbGSM4H-rH7B5nfnE=-gCUc9_o3EnOFY+3aC6w@mail.gmail.com>
References: <52A8EB65.4060800@infinispan.org>
	<52A8ECB9.9000904@redhat.com>	<CA+nfvwRZSF17xMnZzQ5TKhYO3Jjd-kDgN8tjhVXbPHyw-iCo5g@mail.gmail.com>
	<CAFm4XO1SJrZHRbGSM4H-rH7B5nfnE=-gCUc9_o3EnOFY+3aC6w@mail.gmail.com>
Message-ID: <52A997CB.1000102@infinispan.org>



On 12/12/2013 10:35 AM, Sanne Grinovero wrote:
> It all looks so much more complex than getting rid of this ThreadLocal?

I would like to remove it but, by the comments, it looks like an 
optimization. It is keeping 6 Marshall and 6 UnMarshall instances to 
avoid creating them each time you need to (un)marshall an object.

>
> On 12 December 2013 09:01, Dan Berindei <dan.berindei at gmail.com> wrote:
>>
>>
>>
>> On Thu, Dec 12, 2013 at 12:52 AM, David M. Lloyd <david.lloyd at redhat.com>
>> wrote:
>>>
>>> On 12/11/2013 04:47 PM, Pedro Ruivo wrote:
>>>> Hi,
>>>>
>>>> I've created a method to clean a specific ThreadLocal variable from all
>>>> live threads [1].
>>>>
>>>> My goal is to clean the ThreadLocal variables after a cache stops. It's
>>>> kind expensive method (it uses reflection) but I think it is fine.
>>>>
>>>> Currently, I'm using it to clear the Marshaller ThreadLocal in here [2].
>>>>
>>>> Does anyone see any problem with this approach? Maybe it can be used in
>>>> other possible leaking ThreadLocals?
>>>
>>> It's an interesting idea (I've done something similar in the past to
>>> simply drop all thread locals).  I would recommend that you check that
>>> all the JDKs you want to support use the same technique for thread
>>> locals though.  Because these fields are not part of the JDK, they may
>>> not always exist in all environments.
>>
>>
>> Yeah, the implementation of ThreadLocal has changed in the past and is
>> likely to change again in the future. If that happens and we have to support
>> different JDKs with different methods for clearing ThreadLocals, it won't be
>> pretty.

yep, both of you are right. I'm going to try another way :)

>>
>>>
>>> Also, it is important to only ever clean the thread locals of your
>>> current thread, or you're inviting all kinds of bizarre concurrency
>>> problems (maybe even locking threads into infinite loops), especially if
>>> the thread is running and actively using thread locals at the time.
>>
>>
>> Indeed, ThreadLocalMap doesn't look to be thread-safe. I'm not sure if a
>> remote() from another thread can cause an infinite loop like in HashMap
>> because it uses open addressing instead of chaining, but it looks like it
>> may cause a get() for a different ThreadLocal to return the wrong instance.
>> (I would be ok with it if it would only cause breakage for threads using the
>> cache that's being stopped, but it looks like it can touch more than one
>> entry.)
>>
>> I think we shouldn't concern ourselves with actually removing the
>> ThreadLocal from the map, we just have to keep track of the ThreadLocal
>> instances and clean any references to other objects they might have (a la
>> ExternalizerTableProxy). Or maybe give up on ThreadLocals and use a
>> ConcurrentWeakKeyHashMap<Thread, PerThreadInstanceHolder> instead.

I tried to use the proxy approach, but it looks worst since the core 
test suite started to throw OOME. I created a 
PerThreadInstanceHolderProxy with a reference to 
PerThreadInstanceHolder. Each time I created a Proxy, I put it in a list 
and in the stop I clear to PerThreadInstanceHolder.

I'll give it a try with the ConcurrentWeakKeyHashMap.

>>
>> Dan
>>
>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

From sanne at infinispan.org  Thu Dec 12 08:38:01 2013
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 12 Dec 2013 13:38:01 +0000
Subject: [infinispan-dev] Clean ThreadLocals
In-Reply-To: <52A997CB.1000102@infinispan.org>
References: <52A8EB65.4060800@infinispan.org> <52A8ECB9.9000904@redhat.com>
	<CA+nfvwRZSF17xMnZzQ5TKhYO3Jjd-kDgN8tjhVXbPHyw-iCo5g@mail.gmail.com>
	<CAFm4XO1SJrZHRbGSM4H-rH7B5nfnE=-gCUc9_o3EnOFY+3aC6w@mail.gmail.com>
	<52A997CB.1000102@infinispan.org>
Message-ID: <CAFm4XO2tQM2O7sdvDAWjeKwANs3EppR5z49ORB9y94a9+WM61A@mail.gmail.com>

On 12 December 2013 11:02, Pedro Ruivo <pedro at infinispan.org> wrote:
>
>
> On 12/12/2013 10:35 AM, Sanne Grinovero wrote:
>> It all looks so much more complex than getting rid of this ThreadLocal?
>
> I would like to remove it but, by the comments, it looks like an
> optimization. It is keeping 6 Marshall and 6 UnMarshall instances to
> avoid creating them each time you need to (un)marshall an object.

Ah indeed I remember that one, that was an important optimization.
Sorry I got confused as I thought this discussion was about a
different TLocal.

Still, it would be nice to explore alternative solutions, including
contributing to the Marshaller project to better fit the Infinispan
requirements.

Sanne

From sanne at infinispan.org  Thu Dec 12 12:29:42 2013
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 12 Dec 2013 17:29:42 +0000
Subject: [infinispan-dev] Cost of inheritance
In-Reply-To: <CAFm4XO0XsnSsCKN4YZ=Aj-OsrOAk97RB0NLitHx_dPZxvzC2Lw@mail.gmail.com>
References: <CAFm4XO2YnbH7JKJ73NbMRGH5Dts7ZOmx61K8P+6Hx9=VpYtNgQ@mail.gmail.com>
	<5285D6F4.9060005@redhat.com>
	<CAFm4XO0XsnSsCKN4YZ=Aj-OsrOAk97RB0NLitHx_dPZxvzC2Lw@mail.gmail.com>
Message-ID: <CAFm4XO08YZtnKZnZztuQ919-SyhMOO-p60VrRsNv-_VUNQvdLg@mail.gmail.com>

For those looking to use java-object-layout:

it's not longer on GitHub but contributed to OpenJDK:
  http://openjdk.java.net/projects/code-tools/jol/

The author, Aleksey Shipilev, was so nice to get in touch with me to
let us know that the version in OpenJDK has many bugs fixed so better
used that.

Sanne


On 15 November 2013 12:16, Sanne Grinovero <sanne at infinispan.org> wrote:
> On 15 November 2013 08:10, Bela Ban <bban at redhat.com> wrote:
>> Excellent idea of moving fields between parent/sub classes !
>> Which tool did you use to dump the layout of a class ? Following Shane's
>> ref, "Java Object Layout" has been moved...
>
> Seems I was lucky to read that same post a long time ago, and forking
> the repository for the tool:
> https://github.com/Sanne/java-object-layout
>
>
>> I'd like to take a look at some JGroups classes and see if I can reorder
>> fields (although I don't use a lot of inheritance)
>
> nice!
>
> Sanne
>
>>
>> On 11/14/13 10:18 PM, Sanne Grinovero wrote:
>>> In a particular benchmark I'm running, the bottleneck of my system
>>> seems to be the object allocation rate.
>>>
>>> More specifically, in just some minutes I've got about 55GB allocated
>>> just of instances of SingleKeyNonTxInvocationContext
>>> (yes I literally mean GigaBytes)
>>>
>>> and 45GB of org.infinispan.commands.read.GetKeyValueCommand.
>>>
>>> To be clear: these high amounts are caused only by the "shallow" class
>>> instance of these two types, not counting key nor value sizes being
>>> actually moved into/out Infinispan.
>>> Of course it means we're talking about many of these instances, but
>>> also the size of each of them matters, so I've been taking a look at
>>> their definitions.
>>>
>>> Running 64-bit HotSpot VM.
>>> Using compressed references with 3-bit shift.
>>> Objects are 8 bytes aligned.
>>>
>>> # org.infinispan.context.SingleKeyNonTxInvocationContext
>>>
>>>   offset  size          type description
>>>        0    12            (assumed to be the object header + first
>>> field alignment)
>>>       12     1            byte AbstractInvocationContext.contextFlags
>>>       13     3            (alignment/padding gap)
>>>       16     4            Address AbstractInvocationContext.origin
>>>       20     4            WeakReference AbstractInvocationContext.classLoader
>>>       24     1            boolean SingleKeyNonTxInvocationContext.isOriginLocal
>>>       25     1            boolean SingleKeyNonTxInvocationContext.isLocked
>>>       26     2            (alignment/padding gap)
>>>       28     4            Object SingleKeyNonTxInvocationContext.key
>>>       32     4            CacheEntry SingleKeyNonTxInvocationContext.cacheEntry
>>>       36     4            (loss due to the next object alignment)
>>>       40            (object boundary, size estimate)
>>>
>>> I notice two things in here:
>>>   a) we could refactor maybe some code to have less fields in such a
>>> hot allocated type
>>>   b) Lots of space is being wasted in padding!
>>>
>>> If you count the bytes lost because of the various alignment rules: 9
>>> That's almost 25%, about 13GB of used memory!
>>>
>>> Why are there two separate object alignment gaps? That's because the
>>> fields of the parent class need to be grouped, then the child class's
>>> fields are aligned after it.
>>> In other words, if I move the fields from the parent class to the
>>> bottom class I get:
>>>
>>> org.infinispan.context.SingleKeyNonTxInvocationContext
>>>   offset  size        type description
>>>        0    12            (assumed to be the object header + first
>>> field alignment)
>>>       12     1            byte SingleKeyNonTxInvocationContext.contextFlags
>>>       13     1            boolean SingleKeyNonTxInvocationContext.isOriginLocal
>>>       14     1            boolean SingleKeyNonTxInvocationContext.isLocked
>>>       15     1            (alignment/padding gap)
>>>       16     4            Address SingleKeyNonTxInvocationContext.origin
>>>       20     4            ClassLoader SingleKeyNonTxInvocationContext.classLoader
>>>       24     4            Object SingleKeyNonTxInvocationContext.key
>>>       28     4            CacheEntry SingleKeyNonTxInvocationContext.cacheEntry
>>>       32               (object boundary, size estimate)
>>>
>>> which recovers 20% ..
>>>
>>> Looking forward to see simpler class hierarchies in the code ;-)
>>>
>>> Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> --
>> Bela Ban, JGroups lead (http://www.jgroups.org)
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From brmeyer at redhat.com  Thu Dec 12 12:55:00 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 12 Dec 2013 12:55:00 -0500 (EST)
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
	<2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
Message-ID: <595428667.30164908.1386870900128.JavaMail.root@redhat.com>

I finally had a chance to start working with this, a bit, today.  Here's what I've found so far.

In general, I'm seeing 2 types of CL issues come up when testing w/ hibernate-infinispan:

1.) Reliance on the client bundle's CL.  Take the following stack as an example: https://gist.github.com/brmeyer/c8aaa1157a4a951a462c.  Hibernate's InfinispanRegionFactory is building a ConfigurationBuilderHolder.  Parser60#parseTransport eventually gives the ConfigurationBuilderHolder#getClassLoader to Util#loadClass.  But since this thread is happening within the hibernate-infinispan bundle, that CL instance is hibernate-infinispan's BundleWiring.  If hibernate-infinispan's manifest explicitly imports the package being loaded, this works fine.  But, as I hit, that's not usually the case.  This stack fails when it attempted to load org.infinispan.remoting.transport.jgroups.JGroupsTransport.  Adding org.infinispan.remoting.transport.jgroups to our imports worked, but that's not ideal.

2.) Reliance on TCCL.  See GlobalConfigurationBuilder#cl as an example.  TCCL should be avoided at all costs.  Here's an example: https://gist.github.com/brmeyer/141ea83fb632dd126406.  Yes, ConfigurationBuilderHolder could attempt to pass in a CL to GlobalConfigurationBuilder, but we'd run into the same situation for #1.  In this specific example, we're trying to load the "infinispan-core-component-metadata.dat" resource within the infinispan-core bundle, not visible to the hibernate-infinispan bundle CL.

commons already has a step towards a solution: OsgiFileLookup.  However, it scans over *all* bundles activated in the container.  There's certainly performance issues with that, but more importantly can introduce conflicts (multiple versions of Infinispan or client bundles running simultaneously, a resource existing in multiple bundles, etc.).

What we did in Hibernate was to introduce an OSGi-specific implementation of ClassLoader that's aware of what bundles it needs to consider.  In frameworks with multiple bundles/modules, this is definitely more complicated.  For now, we limit the scope to core, entitymanager (JPA), and the "requesting bundle" (the client bundle requesting the Session).  The "requesting bundle" concept was important for us since we scan and rely on the client bundle's entities, mapping files, etc.

There are several routes, but all boil down to relying on OSGi APIs to use Bundles to discover classes and resources, with TCCL & Class#getClassLoader as a just-in-case backup.  How the scope of that Bundle set is defined is largely up to the framework's existing architecture and dependency tree.

What I might recommend as a first step would be expanding/refactoring OsgiFileLookup to include loading classes, but continue to allow it to scan all bundles (for now).  That will at least remove the initial CL issues.  But, that would need to be followed up.

Before I keep going down the rabbit hole, just wanted to see if there were any other thoughts.  I'm making general assumptions without knowing much about Infinispan's architecture.  Thanks! 

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Brett Meyer" <brmeyer at redhat.com>
To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
Sent: Friday, December 6, 2013 11:56:42 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi

Sorry, forgot the link:

[1] https://hibernate.atlassian.net/browse/HHH-8214

Brett Meyer
Software Engineer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Brett Meyer" <brmeyer at redhat.com>
To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
Sent: Friday, December 6, 2013 11:51:33 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi

Randall, that is *definitely* the case and is certainly true for Hibernate.  The work involved:

* correctly resolving ClassLoaders based on the activated bundles
* supporting multiple containers and contexts (container-managed JPA, un-managed JPA/native, etc.)
* fully supporting OSGi/Blueprint services (both for internal services as well as externally-registered)
* bundle scanning
* generally working towards supporting the dynamic nature
* full unit-tests with Arquillian and an OSGi container

It's a matter of holistically supporting the "OSGi way" (for better or worse), as opposed to simply ensuring the library's manifest is correct.

There were a bloody ton of gotchas and caveats I hit along the way.  That's more along the lines of where I might be able to help.

I'm even more interested in this effort so that we can support hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I hit  ClassLoader issues [1].  Some of that may already be resolved.

The next step may simply be giving hibernate-infinispan another shot and correcting things as I find them.  In parallel, feel free to let me know if there's anything else!  ORM supports lots of OSGi-enabled extension points, etc. that are powerful for users, but obviously I don't have the Infinispan knowledge to know what would be necessary.

Thanks!

Brett Meyer
Software Engineer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Randall Hauch" <rhauch at redhat.com>
To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
Sent: Friday, December 6, 2013 10:57:23 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi

Brett, correct me if I?m wrong, but isn?t there a difference in making some library *work* in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled application? For example, making the JAR?s be OSGi bundles is easy and technically makes it possible to deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC what you really want is a BundleActivator or Declarative Services [1] so that the library?s components are readily available in a naturally-OSGi way.

[1] http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html

On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:

> + infinispan-dev
> 
> Thanks for offering to look into this Brett!
> We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
> Tristan can get you up to speed with this.
> 
> 
>>> Sanne/Galder/Pete,
>>> 
>>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>> 
>>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>>> 
>>> Brett Meyer
>>> Software Engineer
>>> Red Hat, Hibernate ORM
>>> 
>> 
> 
> 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



From vblagoje at redhat.com  Thu Dec 12 12:57:57 2013
From: vblagoje at redhat.com (Vladimir Blagojevic)
Date: Thu, 12 Dec 2013 12:57:57 -0500
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <59C835EB-E2C6-4EA0-BB1A-DCE4F5D182DB@redhat.com>
References: <529F6374.3070901@redhat.com>	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>	<52A1FD24.7000007@redhat.com>
	<59C835EB-E2C6-4EA0-BB1A-DCE4F5D182DB@redhat.com>
Message-ID: <52A9F925.9080207@redhat.com>

On 12/6/2013, 11:40 AM, Mircea Markus wrote:
> Hmm I think you could leverage the parallel iteration from the EquivalentConcurrentHashMapV8 there instead of writing it yourself ;)
>
Hi, for those interested in parallel M/R I have uploaded my first 
proposal that will hopefully, with your input, soon turn into a PR. A 
couple of things to note: we do parallel iteration using JDK8 
ConcurrentHashMap port (see DefaultDataContainer). Doing parallel 
iteration makes sense when we have to iterate over all keys in data 
container and check whether each individual key should be traversed 
(using Mircea's filter). Sometimes it does not make sense to iterate 
over all keys as input keys are provided to M/R task and input keys 
represent only a small subset of all keys in the data container. Even in 
those cases we do parallel execution but in a slightly different 
approach (again see DefaultDataContainer).

Please provide feedback directly on 
https://github.com/vblagoje/infinispan/tree/t_2284_mm or if you have 
some general comments here on dev list.

Thanks for you feedback,
Vladimir

From mmarkus at redhat.com  Fri Dec 13 05:06:06 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Fri, 13 Dec 2013 05:06:06 -0500 (EST)
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <52A5F0DB.7090401@redhat.com>
References: <529F6374.3070901@redhat.com>
	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
	<52A57AD1.1040602@redhat.com> <52A5DFF8.3080107@redhat.com>
	<52A5F0DB.7090401@redhat.com>
Message-ID: <F526A97C-C6C1-4941-AA1F-973B39CB9445@redhat.com>

Sent from my iPhone

>> On 9 Dec 2013, at 16:45, Radim Vansa <rvansa at redhat.com> wrote:
>> 
>> On 12/09/2013 04:21 PM, Vladimir Blagojevic wrote:
>> Radim, these are some very good ideas. And I think we should put them on
>> the roadmap.
> Do you have any JIRA where this could be marked down?
>> 
>> Also, I like your ExecutorAllCompletionService, however, I think it will
>> not work in this case as we often do not have exclusive access to the
>> underlying executor service used in ExecutorAllCompletionService. There
>> might be some other Infinispan part using the same executor service
>> which will screw up the logic of incrementing and decrementing tasks. It
>> seems like you need to do counting logic based on some id or smth similar.
> You're right - I am not really sure which threadpools does M/R use. And 
> in fact it might happen that currently multiple executions using the 
> persistence executor would interfere. I should fix the service to add 
> the ID and multiplex internally! Created [1] for that.
> Shouldn't there be separate threadpools for map and reduce tasks? I 
> mean, two threadpools, because used mapper pool should not block another 
> reduce tasks to be executed (otherwise there might be a deadlock between 
> the threadpools and bounded queue in collector).

For the mapper at least (i think reducer as well) we're planning to rely on the Fork/Join fwk. This doesn't allow configuring external pool, which is not necessarely a bad thing, considering the large number of pool configs we provide to the user.

> 
> Radim
> 
> [1] https://issues.jboss.org/browse/ISPN-3800
>> 
>>> On 12/9/2013, 3:09 AM, Radim Vansa wrote:
>>> There is one thing I really don't like about the current implementation:
>>> DefaultCollector. And any other collection that keeps one (or more)
>>> object per entry.
>>> We can't assume that if you double the number of objects in memory (and
>>> in fact, if you map entry to bigger object, you do that), they'd still
>>> fit into it. Moreover, if you map the objects from cache store as well.
>>> I believe we have to use Collector implemented as bounded queue, and
>>> start reduction phase on the entries that have been mapped in parallel
>>> to the mapper phase. Otherwise, say hello to OOME.
>>> 
>>> Cheers
>>> 
>>> Radim
>>> 
>>> PS: And don't keep all the futures just to check that all tasks have
>>> been finished - use ExecutorAllCompletionService instead.
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From mmarkus at redhat.com  Fri Dec 13 05:06:19 2013
From: mmarkus at redhat.com (Mircea Markus)
Date: Fri, 13 Dec 2013 05:06:19 -0500 (EST)
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <52A57AD1.1040602@redhat.com>
References: <529F6374.3070901@redhat.com>
	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>
	<52A57AD1.1040602@redhat.com>
Message-ID: <C4EE9C88-024E-44B0-B232-58AE1A967BFE@redhat.com>


> On 9 Dec 2013, at 08:10, Radim Vansa <rvansa at redhat.com> wrote:
> 
> There is one thing I really don't like about the current implementation: 
> DefaultCollector. And any other collection that keeps one (or more) 
> object per entry.
> We can't assume that if you double the number of objects in memory (and 
> in fact, if you map entry to bigger object, you do that), they'd still 
> fit into it. Moreover, if you map the objects from cache store as well.
> I believe we have to use Collector implemented as bounded queue, and 
> start reduction phase on the entries that have been mapped in parallel 
> to the mapper phase. Otherwise, say hello to OOME.

Agreed that's indeed a problem. Not sure it's related to parallel iteration though :-)

> 
> Cheers
> 
> Radim
> 
> PS: And don't keep all the futures just to check that all tasks have 
> been finished - use ExecutorAllCompletionService instead.
> 
>> On 12/06/2013 05:18 PM, Mircea Markus wrote:
>> Thanks Vladimir, I like the hands on approach!
>> Adding -dev, there's a lot of interest around the parallel M/R so I think others will have some thoughts on it as well.
>> 
>> So what you're basically doing in your branch is iterate over all the keys in the cache and then for each key invoke the mapping in a separate thread. Whilst this would work, I think it has some drawbacks:
>> - the iteration over the keys in the container happens in sequence, albeit the mapping phases happening in parallel. This speeds things up a bit but not as much as having the iteration
>> happening in parallel, especially when the mapper is fast, which I think it's pretty common.
>> - the StatelessTask + some smaller objects are being created for each iterated key. That's a lot of noise for the GC imo
>> 
>> I think delegating the parallel iteration to the DataContainer (similar to AdvancedCacheLoader.process (Executor)) would be a better approach IMO:
>> - the logic is reusable for other components as well, such as querying (to implement full-scan-like search, or a general purpose parallel iterator over the keys
>> - object creation is reduced
>> - the DefaultDetaContainer uses an EquivalentConcurrentHashMapV8 for holding the entries, which already supports parallel iteration so the heavy lifting is already in place
>> 
>>> On Dec 4, 2013, at 5:16 PM, Vladimir Blagojevic <vblagoje at redhat.com> wrote:
>>> 
>>> Here is my M/R parallel execution solution updated to master https://github.com/vblagoje/infinispan/tree/t_2284_new
>>> 
>>> Now, I'll work on your solution which I am starting to like actually the more I think about it. Although I have to admit that I would eviscerate some of your interfaces like these KeyFilters into more prominent packages so we can all use the same interfaces. Also I would see if we can genericize some of your interfaces and implementations.
>>> 
>>> Will keep you updated.
>>> 
>>> Vladimir
>> Cheers,
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From galder at redhat.com  Fri Dec 13 08:44:25 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Fri, 13 Dec 2013 14:44:25 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <52A19CC3.40807@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<52A19CC3.40807@redhat.com>
Message-ID: <C5767B2C-3507-470A-A0FE-19A2D6A102A6@redhat.com>


On Dec 6, 2013, at 10:45 AM, Radim Vansa <rvansa at 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 filtering.

What do you mean by runtime parameter exactly? Can you give a concrete example of what you want to achieve that is not possible with what I've written up?

> 2) setting ack/no ack in listener, and then configuring server-wise whether you should ack each / only last event sounds weird. I'd replace the boolean with enum { NO_ACK, ACK_EACH, ACK_LAST }.

Makes a lot of sense, +1.

> 3) should the client provide source id when registering listener or when starting RemoteCacheManager? No API for that.

Every operation will require a source ID from now on, so clients must provide it from first operation sent to the server. From a Java client perspective, you'd have this from the start via the configuration.

> 4) clustered events design does not specify any means to replicating the clustered event listener - all it does is that you register the listener on one node and the other nodes then route events to this node, until the node dies/deregisters the listener. No replication. Please specify, how should it piggyback on clustered events, and how should the listener list be replicated.

In clustered listeners, the other nodes you talk about are gonna need to know about the clustered listeners so that they route events. Some kind of information about these clustered listeners will need to be sent around the cluster. The exact details are probably implementation details but we have a clustered registry already in place for this kind of things. In any case, it'd make a lot of sense that both use cases reuse as much as logic in this area.

> 5) non-acked events: how exactly do you expect the ack data to be replicated, and updated? I see three options:
> A) Let non-acked list be a part of the listener record in replicated cache, and the primary owner which executes the event should update these via delta messages. I guess for proper reliability it should add operation record synchronously before confirming the operation to the originator, and then it might asynchronously remove it after the ack from client. When a node becomes primary owner, it should send events to client for all non-acked events.
> B) Having the non-acked list attached directly to cache entry (updating it together with regular backup), and then asynchronously updating the non-ack list after ack comes
> C) Separate cache for acks by entry keys, similar to B, consistent hash synced with the main entry cache

Definitely not B. I don't wanna tie the internal cache entry to the ACKs. The two should be independent. Either C or A. For C, you'd wished to have a single cache for all listeners+caches, but you'd have to think about the keys and to have the same consistent hash, you'd have to have same keys. A might be better, but you certainly don't want this ACK info in a replicated structure. You'd want ACKs in a distributed cache preferably, and clustered listener info in the clustered replicated registry.

Cheers,

> 
> Radim
> 
> 
> On 12/05/2013 05:16 PM, Galder Zamarre?o wrote:
>> 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 have another read and let the list know what you think of it?
>> 
>> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
>> 
>> Cheers,
>> --
>> Galder Zamarre?o
>> galder at redhat.com
>> twitter.com/galderz
>> 
>> Project Lead, Escalante
>> http://escalante.io
>> 
>> Engineer, Infinispan
>> http://infinispan.org
>> 
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
> 


--
Galder Zamarre?o
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org



From rvansa at redhat.com  Fri Dec 13 09:11:17 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 13 Dec 2013 15:11:17 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <C5767B2C-3507-470A-A0FE-19A2D6A102A6@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<52A19CC3.40807@redhat.com>
	<C5767B2C-3507-470A-A0FE-19A2D6A102A6@redhat.com>
Message-ID: <52AB1585.7030602@redhat.com>

On 12/13/2013 02:44 PM, Galder Zamarre?o wrote:
> On Dec 6, 2013, at 10:45 AM, Radim Vansa <rvansa at 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 filtering.
> What do you mean by runtime parameter exactly? Can you give a concrete example of what you want to achieve that is not possible with what I've written up?

As I stressed, if the client wants to listen for events on key_123456, 
then you can deploy a filter matching key_{number} (and additional 
constraints) but the 123456 is not known at deployment time.

>
>> 2) setting ack/no ack in listener, and then configuring server-wise whether you should ack each / only last event sounds weird. I'd replace the boolean with enum { NO_ACK, ACK_EACH, ACK_LAST }.
> Makes a lot of sense, +1.
>
>> 3) should the client provide source id when registering listener or when starting RemoteCacheManager? No API for that.
> Every operation will require a source ID from now on, so clients must provide it from first operation sent to the server. From a Java client perspective, you'd have this from the start via the configuration.
>
>> 4) clustered events design does not specify any means to replicating the clustered event listener - all it does is that you register the listener on one node and the other nodes then route events to this node, until the node dies/deregisters the listener. No replication. Please specify, how should it piggyback on clustered events, and how should the listener list be replicated.
> In clustered listeners, the other nodes you talk about are gonna need to know about the clustered listeners so that they route events. Some kind of information about these clustered listeners will need to be sent around the cluster. The exact details are probably implementation details but we have a clustered registry already in place for this kind of things. In any case, it'd make a lot of sense that both use cases reuse as much as logic in this area.

OK, this is probably the desired behaviour, it just is not covered by 
the Clustered Events design draft. Probably something to add - I'll ping 
Mircea about that. And you're right that it would make a lot of sense to 
have shared structure for the listeners, and two implementations of the 
delivery boy (one to the node where a clustered event has been 
registered and second to local component handling HotRod clients).

>
>> 5) non-acked events: how exactly do you expect the ack data to be replicated, and updated? I see three options:
>> A) Let non-acked list be a part of the listener record in replicated cache, and the primary owner which executes the event should update these via delta messages. I guess for proper reliability it should add operation record synchronously before confirming the operation to the originator, and then it might asynchronously remove it after the ack from client. When a node becomes primary owner, it should send events to client for all non-acked events.
>> B) Having the non-acked list attached directly to cache entry (updating it together with regular backup), and then asynchronously updating the non-ack list after ack comes
>> C) Separate cache for acks by entry keys, similar to B, consistent hash synced with the main entry cache
> Definitely not B. I don't wanna tie the internal cache entry to the ACKs. The two should be independent. Either C or A. For C, you'd wished to have a single cache for all listeners+caches, but you'd have to think about the keys and to have the same consistent hash, you'd have to have same keys. A might be better, but you certainly don't want this ACK info in a replicated structure. You'd want ACKs in a distributed cache preferably, and clustered listener info in the clustered replicated registry.
There already is some CH implementation which aims at sharing the same 
distribution for all caches, SyncConsistentHash. Is there some problem 
with C and forcing this for the caches? Dan?

Radim

From rvansa at redhat.com  Fri Dec 13 09:18:47 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 13 Dec 2013 15:18:47 +0100
Subject: [infinispan-dev] Design for clustered events
Message-ID: <52AB1747.4050409@redhat.com>

Hi Mircea,

as we were discussing the design of remote Hot Rod events with Galder, 
the document regarding clustered events does not cover how should the 
clustered listener information be propagated in case of topology change. 
Could you add this info (or at least TODO so that we can see that there 
is more work required on the document). Also, situations related to such 
changes (such as reliability guarantees in case of node crash/join) 
should be specified.

Thanks

Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA


From galder at redhat.com  Fri Dec 13 09:40:34 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Fri, 13 Dec 2013 15:40:34 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
Message-ID: <9AD3BF60-7005-4DD5-A58C-2ED4F89167B2@redhat.com>


On Dec 6, 2013, at 3:52 PM, Mircea Markus <mmarkus at 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 allow upgrading the java and Cpp clients independently.

Hmmm, not sure about the usability of intelligence level in this context. We added that flag to deal with different responses from server, so there's always a request first. Independent upgrading is possible today, since the server talks earlier protocol versions. So, Java clients could talk protocol version 1.4 and Cpp clients 1.3. When Cpp clients support all features in 1.4, they can start talking that protocol.

Also, the source ID can be any byte array. If clients are not interested in registering listeners, they can just send a empty byte[]. When they want to register listeners, then it becomes important to have a good source ID.

> In one of our discussions, you've also mentioned that you'd want to use the cluster listeners as a foundation for this functionality. That doesn't seem to be the case from the document, or? Not that it's a bad thing, just that I want to clarify the relation between the two.

In both the clustered listeners and remote listeners, we're gonna need some kind of cluster wide information about the listeners. For clustered listeners, it's needed in order to route events. For remote listeners, pretty much the same thing. If a client C registers a listener L in server S1, and then a distributed put arrives in S2, somehow S2 is gonna need to know that it needs to send an event remotely. I see both using the clustered registry for this.

The difference between the two is really the communication layer and protocol used to send those events. For clustered listeners, you'd send them through JGroups, for remote events, they go through Netty, formatted as per Hot Rod protocol.

> Another way to handle connection management, based on clustered listeners, would be:
> - the node on which the listeners ID hashes is the only one responsible for piggyback notifications to the remote client
> - it creates a cluster listener to be notified on what to send to the client (can make use cluster listener's filtering and transformer capabilities here)

>From a connection management perspective, that's an interesting idea, but there's a slight mistmatch in the filtering area. As shown in the design document for remote events, the clustered listener's  API receives different information to the callback API for remote events. IOW, for remote events, there's stuff such as source ID of the Hot Rod protocol operation and the source ID for which the event is directed. 

The convertor stuff would work probably as it is, but the callback API you wrote for metadata might be a bit limited (no previous value, no previous metadata)

> Comparing the two approaches: this approach reuses some code (not sure how much, we might be able to do that anyway) from the cluster listeners and also reduces the number of connections required between clint and server, but at the cost of performance/network hops. Also the number of connections a client is required to have hasn't been a problem yet.
> 
> One more note on ST: during ST a node might receive the same notification multiple times (from old owner and new owner). I guess it makes sense documenting that?

I already mentioned something along those lines in the `Non-`ACK`d events` section.

Cheers,

> 
> On Dec 5, 2013, at 4:16 PM, Galder Zamarre?o <galder at redhat.com> wrote:
> 
>> 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 have another read and let the list know what you think of it?
>> 
>> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
> 
> +1. Can we include the notification ack in the optionals category?
> What about leaving these as the last bit to be implemented? If time allows (not to delay the release) we can add them, otherwise just add them in future iterations?
> 
> 
>> 
>> Cheers,
>> --
>> Galder Zamarre?o
>> galder at redhat.com
>> twitter.com/galderz
>> 
>> Project Lead, Escalante
>> http://escalante.io
>> 
>> Engineer, Infinispan
>> http://infinispan.org
>> 
> 
> Cheers,
> -- 
> Mircea Markus
> Infinispan lead (www.infinispan.org)
> 
> 
> 
> 


--
Galder Zamarre?o
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org



From galder at redhat.com  Fri Dec 13 09:49:32 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Fri, 13 Dec 2013 15:49:32 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <52A1EA82.3000500@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
	<52A1EA82.3000500@redhat.com>
Message-ID: <5135A77E-971C-4147-ABBD-E399C636A4F0@redhat.com>


On Dec 6, 2013, at 4:17 PM, Radim Vansa <rvansa at 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 about its own change?

If the call lands in a non-owner, it's probably simpler for the non-owner to send the notification there and then. ACK information tracking would probably be distributed, in which case it'd need to deal with potential failure of the primary owner.

Cheers,
--
Galder Zamarre?o
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org



From galder at redhat.com  Fri Dec 13 09:51:20 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Fri, 13 Dec 2013 15:51:20 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <D5CECCDB-954C-4290-8B41-474F3186B5FA@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
	<52A20B80.60601@redhat.com>
	<D5CECCDB-954C-4290-8B41-474F3186B5FA@redhat.com>
Message-ID: <27DE88C9-393A-44CD-AA8B-77C3932CFC97@redhat.com>


On Dec 9, 2013, at 6:47 PM, Mircea Markus <mmarkus at 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 can be built on the fly (we already do that with the embedded query DSL).
> There are some nice advantages of doing this: build the filter and the listener at runtime, in a language independent manner(assuming query DSL is migrated), with an API customers are already used to. 

I'll look into that. Thanks for the heads up.

Cheers,

> 
> 
> On Dec 6, 2013, at 5:38 PM, Dennis Reed <dereed at redhat.com> wrote:
> 
>> 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 Cpp clients independently.
>> 
>> Instead of a new intelligence level, if the client told the server what 
>> features it supports when connecting this could be done more fine-grained,
>> so that a client could support some subset of functionality (instead of 
>> being forced to implement the specific extentions in one of the 
>> pre-defined intelligence levels).
>> 
>> -Dennis
>> 
>>> In one of our discussions, you've also mentioned that you'd want to use the cluster listeners as a foundation for this functionality. That doesn't seem to be the case from the document, or? Not that it's a bad thing, just that I want to clarify the relation between the two. Another way to handle connection management, based on clustered listeners, would be:
>>> - the node on which the listeners ID hashes is the only one responsible for piggyback notifications to the remote client
>>> - it creates a cluster listener to be notified on what to send to the client (can make use cluster listener's filtering and transformer capabilities here)
>>> 
>>> Comparing the two approaches: this approach reuses some code (not sure how much, we might be able to do that anyway) from the cluster listeners and also reduces the number of connections required between clint and server, but at the cost of performance/network hops. Also the number of connections a client is required to have hasn't been a problem yet.
>>> 
>>> One more note on ST: during ST a node might receive the same notification multiple times (from old owner and new owner). I guess it makes sense documenting that?
>>> 
>>> On Dec 5, 2013, at 4:16 PM, Galder Zamarre?o <galder at redhat.com> wrote:
>>> 
>>>> 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 have another read and let the list know what you think of it?
>>>> 
>>>> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
>>> +1. Can we include the notification ack in the optionals category?
>>> What about leaving these as the last bit to be implemented? If time allows (not to delay the release) we can add them, otherwise just add them in future iterations?
>>> 
>>> 
>>>> Cheers,
>>>> --
>>>> Galder Zamarre?o
>>>> galder at redhat.com
>>>> twitter.com/galderz
>>>> 
>>>> Project Lead, Escalante
>>>> http://escalante.io
>>>> 
>>>> Engineer, Infinispan
>>>> http://infinispan.org
>>>> 
>>> Cheers,
>> 
>> _______________________________________________
>> 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



From rvansa at redhat.com  Fri Dec 13 10:33:59 2013
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 13 Dec 2013 16:33:59 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <5135A77E-971C-4147-ABBD-E399C636A4F0@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
	<52A1EA82.3000500@redhat.com>
	<5135A77E-971C-4147-ABBD-E399C636A4F0@redhat.com>
Message-ID: <52AB28E7.3080706@redhat.com>

On 12/13/2013 03:49 PM, Galder Zamarre?o wrote:
> On Dec 6, 2013, at 4:17 PM, Radim Vansa <rvansa at 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 about its own change?
> If the call lands in a non-owner, it's probably simpler for the non-owner to send the notification there and then. ACK information tracking would probably be distributed, in which case it'd need to deal with potential failure of the primary owner.

I don't think I understand that properly. The node responsible for 
notifying the client is either primary owner, or operation origin (where 
the write has landed in fact). Previously, we were saying that the 
responsible node should be the primary owner - now you say that the 
origin. When the cluster is accessed only remotely, it does not have 
much performance impact (as these two are mostly the same node), but 
with cluster in compatibility mode the decision could affect the 
performance a lot.
So, do you think that this should be the origin (easier to implement, 
with access to distributed ack registry it can retrieve the information, 
but with higher latency as the ack info is probably affine to the entry 
itself)
or primary owner (in this case you'd have to propagate the source ID 
with the write command).
Btw., what should be the source ID for operations coming from library 
mode? JGroups address of the node?

Radim

>
> Cheers,
> --
> Galder Zamarre?o
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA


From emmanuel at hibernate.org  Fri Dec 13 11:08:05 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 13 Dec 2013 17:08:05 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
Message-ID: <20131213160805.GA12937@hibernate.org>

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 / converter impls have a @FilterId() / @ConverterId or
should even the id be configured as late binding?

== Custom event contents

I an not following, is the custom content always received as byte[] by
the client?  Or is the generic parameter K in
RemoteCacheEntryCustomEvent<K> the actual return type of getEventData() ?

I'd love (in Java) to declare the returned type of the converter via
generics in the RemoteConverter impl (class SomeRC<String> extends
RemoteConverter<String> {}) and somehow use that information on
the client side.

== 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 query I want to run. Not only that but I'd love to be able to
add a continuous query on the fly and disable it on the fly as well per
client. For that filters and converters are not flexible enough.

What is missing is the ability to pass parameters from the client to
the remote filter and remote converter. Parameters should be provided
*per client*. Say Client 1 register the continuous query listener with
"where age > 19" and client 2 registers the CQ listener with "where name
= emmanuel". The filter knowing for which client it filters, it will be able to only
return the keys that match the query.

Another useful but not fundamental notion is the ability for a client to
enlist the same filter id / converter id tuple with different
parameters. The same client might be interested in several different
queries.

BTW have you considered some kind of multiplexing mechanism in case the
several client listeners on the same client are interested in the same
event?

Emmanuel

On Thu 2013-12-05 17:16, Galder Zamarre?o wrote:
> 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 have another read and let the list know what you think of it?
> 
> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
> 
> 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

From emmanuel at hibernate.org  Fri Dec 13 11:12:08 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 13 Dec 2013 17:12:08 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <27DE88C9-393A-44CD-AA8B-77C3932CFC97@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
	<52A20B80.60601@redhat.com>
	<D5CECCDB-954C-4290-8B41-474F3186B5FA@redhat.com>
	<27DE88C9-393A-44CD-AA8B-77C3932CFC97@redhat.com>
Message-ID: <20131213161208.GB12937@hibernate.org>

I think it's a good idea but that's essentially continuous query.
My guts tell me you still want the low level plumbing and actual
imperative code for additional usecases.

On Fri 2013-12-13 15:51, Galder Zamarre?o wrote:
> 
> On Dec 9, 2013, at 6:47 PM, Mircea Markus <mmarkus at 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 can be built on the fly (we already do that with the embedded query DSL).
> > There are some nice advantages of doing this: build the filter and the listener at runtime, in a language independent manner(assuming query DSL is migrated), with an API customers are already used to. 
> 
> I'll look into that. Thanks for the heads up.
> 
> Cheers,
> 
> > 
> > 
> > On Dec 6, 2013, at 5:38 PM, Dennis Reed <dereed at redhat.com> wrote:
> > 
> >> 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 Cpp clients independently.
> >> 
> >> Instead of a new intelligence level, if the client told the server what 
> >> features it supports when connecting this could be done more fine-grained,
> >> so that a client could support some subset of functionality (instead of 
> >> being forced to implement the specific extentions in one of the 
> >> pre-defined intelligence levels).
> >> 
> >> -Dennis
> >> 
> >>> In one of our discussions, you've also mentioned that you'd want to use the cluster listeners as a foundation for this functionality. That doesn't seem to be the case from the document, or? Not that it's a bad thing, just that I want to clarify the relation between the two. Another way to handle connection management, based on clustered listeners, would be:
> >>> - the node on which the listeners ID hashes is the only one responsible for piggyback notifications to the remote client
> >>> - it creates a cluster listener to be notified on what to send to the client (can make use cluster listener's filtering and transformer capabilities here)
> >>> 
> >>> Comparing the two approaches: this approach reuses some code (not sure how much, we might be able to do that anyway) from the cluster listeners and also reduces the number of connections required between clint and server, but at the cost of performance/network hops. Also the number of connections a client is required to have hasn't been a problem yet.
> >>> 
> >>> One more note on ST: during ST a node might receive the same notification multiple times (from old owner and new owner). I guess it makes sense documenting that?
> >>> 
> >>> On Dec 5, 2013, at 4:16 PM, Galder Zamarre?o <galder at redhat.com> wrote:
> >>> 
> >>>> 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 have another read and let the list know what you think of it?
> >>>> 
> >>>> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
> >>> +1. Can we include the notification ack in the optionals category?
> >>> What about leaving these as the last bit to be implemented? If time allows (not to delay the release) we can add them, otherwise just add them in future iterations?
> >>> 
> >>> 
> >>>> Cheers,
> >>>> --
> >>>> Galder Zamarre?o
> >>>> galder at redhat.com
> >>>> twitter.com/galderz
> >>>> 
> >>>> Project Lead, Escalante
> >>>> http://escalante.io
> >>>> 
> >>>> Engineer, Infinispan
> >>>> http://infinispan.org
> >>>> 
> >>> Cheers,
> >> 
> >> _______________________________________________
> >> 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

From eric.wittmann at redhat.com  Mon Dec 16 09:00:33 2013
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 16 Dec 2013 09:00:33 -0500
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <595428667.30164908.1386870900128.JavaMail.root@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
	<2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
	<595428667.30164908.1386870900128.JavaMail.root@redhat.com>
Message-ID: <52AF0781.7010400@redhat.com>

I wanted to add that in the Overlord group we're also looking into using 
ISPN in OSGi.  Our directive is to get our projects running in Fuse 6.1.

To that end I've been working on getting Overlord:S-RAMP up and running, 
which requires both ModeShape and ISPN.

Additionally, Gary Brown uses ISPN in Overlord:RTGov and so will need to 
get it working directly (no ModeShape) in Fuse 6.1.

I've made some progress on my end but have run into some of the same 
issues as Brett.

An additional issue I hit was the use of Java's ServiceLoader for 
org.infinispan.configuration.parsing.ConfigurationParser.  None of the 
parsers get loaded because ServiceLoader doesn't work particularly well 
in OSGi.  We had this same issue in S-RAMP (we use ServiceLoader in a 
few places).  I solved it by using the OSGi Service Registry when 
running in an OSGi container, but continuing to use ServiceLoader otherwise.

In any case - I was wondering if anyone thought it might be a good idea 
to create a git repo where we can create some test OSGi applications 
that use ISPN and can be deployed (e.g. to Fuse).  This would be for 
testing purposes only - to shake out problems.  Might be useful for 
collaboration?

-Eric


On 12/12/2013 12:55 PM, Brett Meyer wrote:
> I finally had a chance to start working with this, a bit, today.  Here's what I've found so far.
>
> In general, I'm seeing 2 types of CL issues come up when testing w/ hibernate-infinispan:
>
> 1.) Reliance on the client bundle's CL.  Take the following stack as an example: https://gist.github.com/brmeyer/c8aaa1157a4a951a462c.  Hibernate's InfinispanRegionFactory is building a ConfigurationBuilderHolder.  Parser60#parseTransport eventually gives the ConfigurationBuilderHolder#getClassLoader to Util#loadClass.  But since this thread is happening within the hibernate-infinispan bundle, that CL instance is hibernate-infinispan's BundleWiring.  If hibernate-infinispan's manifest explicitly imports the package being loaded, this works fine.  But, as I hit, that's not usually the case.  This stack fails when it attempted to load org.infinispan.remoting.transport.jgroups.JGroupsTransport.  Adding org.infinispan.remoting.transport.jgroups to our imports worked, but that's not ideal.
>
> 2.) Reliance on TCCL.  See GlobalConfigurationBuilder#cl as an example.  TCCL should be avoided at all costs.  Here's an example: https://gist.github.com/brmeyer/141ea83fb632dd126406.  Yes, ConfigurationBuilderHolder could attempt to pass in a CL to GlobalConfigurationBuilder, but we'd run into the same situation for #1.  In this specific example, we're trying to load the "infinispan-core-component-metadata.dat" resource within the infinispan-core bundle, not visible to the hibernate-infinispan bundle CL.
>
> commons already has a step towards a solution: OsgiFileLookup.  However, it scans over *all* bundles activated in the container.  There's certainly performance issues with that, but more importantly can introduce conflicts (multiple versions of Infinispan or client bundles running simultaneously, a resource existing in multiple bundles, etc.).
>
> What we did in Hibernate was to introduce an OSGi-specific implementation of ClassLoader that's aware of what bundles it needs to consider.  In frameworks with multiple bundles/modules, this is definitely more complicated.  For now, we limit the scope to core, entitymanager (JPA), and the "requesting bundle" (the client bundle requesting the Session).  The "requesting bundle" concept was important for us since we scan and rely on the client bundle's entities, mapping files, etc.
>
> There are several routes, but all boil down to relying on OSGi APIs to use Bundles to discover classes and resources, with TCCL & Class#getClassLoader as a just-in-case backup.  How the scope of that Bundle set is defined is largely up to the framework's existing architecture and dependency tree.
>
> What I might recommend as a first step would be expanding/refactoring OsgiFileLookup to include loading classes, but continue to allow it to scan all bundles (for now).  That will at least remove the initial CL issues.  But, that would need to be followed up.
>
> Before I keep going down the rabbit hole, just wanted to see if there were any other thoughts.  I'm making general assumptions without knowing much about Infinispan's architecture.  Thanks!
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Brett Meyer" <brmeyer at redhat.com>
> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
> Sent: Friday, December 6, 2013 11:56:42 AM
> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>
> Sorry, forgot the link:
>
> [1] https://hibernate.atlassian.net/browse/HHH-8214
>
> Brett Meyer
> Software Engineer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Brett Meyer" <brmeyer at redhat.com>
> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
> Sent: Friday, December 6, 2013 11:51:33 AM
> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>
> Randall, that is *definitely* the case and is certainly true for Hibernate.  The work involved:
>
> * correctly resolving ClassLoaders based on the activated bundles
> * supporting multiple containers and contexts (container-managed JPA, un-managed JPA/native, etc.)
> * fully supporting OSGi/Blueprint services (both for internal services as well as externally-registered)
> * bundle scanning
> * generally working towards supporting the dynamic nature
> * full unit-tests with Arquillian and an OSGi container
>
> It's a matter of holistically supporting the "OSGi way" (for better or worse), as opposed to simply ensuring the library's manifest is correct.
>
> There were a bloody ton of gotchas and caveats I hit along the way.  That's more along the lines of where I might be able to help.
>
> I'm even more interested in this effort so that we can support hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I hit  ClassLoader issues [1].  Some of that may already be resolved.
>
> The next step may simply be giving hibernate-infinispan another shot and correcting things as I find them.  In parallel, feel free to let me know if there's anything else!  ORM supports lots of OSGi-enabled extension points, etc. that are powerful for users, but obviously I don't have the Infinispan knowledge to know what would be necessary.
>
> Thanks!
>
> Brett Meyer
> Software Engineer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Randall Hauch" <rhauch at redhat.com>
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
> Sent: Friday, December 6, 2013 10:57:23 AM
> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>
> Brett, correct me if I?m wrong, but isn?t there a difference in making some library *work* in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled application? For example, making the JAR?s be OSGi bundles is easy and technically makes it possible to deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC what you really want is a BundleActivator or Declarative Services [1] so that the library?s components are readily available in a naturally-OSGi way.
>
> [1] http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html
>
> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>
>> + infinispan-dev
>>
>> Thanks for offering to look into this Brett!
>> We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
>> Tristan can get you up to speed with this.
>>
>>
>>>> Sanne/Galder/Pete,
>>>>
>>>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>>>
>>>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>>>>
>>>> Brett Meyer
>>>> Software Engineer
>>>> Red Hat, Hibernate ORM
>>>>
>>>
>>
>> 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
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

From sanne at hibernate.org  Mon Dec 16 10:08:01 2013
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 16 Dec 2013 15:08:01 +0000
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <52AF0781.7010400@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
	<2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
	<595428667.30164908.1386870900128.JavaMail.root@redhat.com>
	<52AF0781.7010400@redhat.com>
Message-ID: <CAFm4XO2W0MiDYw=8cbXPJ9_xo3r=4ZPK_miHNRCaLs3EB21Y7w@mail.gmail.com>

Hi Eric,
thanks that sounds great, having a solid collection of tests is
probably the most usefull specification for what we need to achieve.

@Infinispan team: could we add such tests in the Infinispan
repository? I think that's where they belong.

Sanne

On 16 December 2013 14:00, Eric Wittmann <eric.wittmann at redhat.com> wrote:
> I wanted to add that in the Overlord group we're also looking into using
> ISPN in OSGi.  Our directive is to get our projects running in Fuse 6.1.
>
> To that end I've been working on getting Overlord:S-RAMP up and running,
> which requires both ModeShape and ISPN.
>
> Additionally, Gary Brown uses ISPN in Overlord:RTGov and so will need to get
> it working directly (no ModeShape) in Fuse 6.1.
>
> I've made some progress on my end but have run into some of the same issues
> as Brett.
>
> An additional issue I hit was the use of Java's ServiceLoader for
> org.infinispan.configuration.parsing.ConfigurationParser.  None of the
> parsers get loaded because ServiceLoader doesn't work particularly well in
> OSGi.  We had this same issue in S-RAMP (we use ServiceLoader in a few
> places).  I solved it by using the OSGi Service Registry when running in an
> OSGi container, but continuing to use ServiceLoader otherwise.
>
> In any case - I was wondering if anyone thought it might be a good idea to
> create a git repo where we can create some test OSGi applications that use
> ISPN and can be deployed (e.g. to Fuse).  This would be for testing purposes
> only - to shake out problems.  Might be useful for collaboration?
>
> -Eric
>
>
>
> On 12/12/2013 12:55 PM, Brett Meyer wrote:
>>
>> I finally had a chance to start working with this, a bit, today.  Here's
>> what I've found so far.
>>
>> In general, I'm seeing 2 types of CL issues come up when testing w/
>> hibernate-infinispan:
>>
>> 1.) Reliance on the client bundle's CL.  Take the following stack as an
>> example: https://gist.github.com/brmeyer/c8aaa1157a4a951a462c.  Hibernate's
>> InfinispanRegionFactory is building a ConfigurationBuilderHolder.
>> Parser60#parseTransport eventually gives the
>> ConfigurationBuilderHolder#getClassLoader to Util#loadClass.  But since this
>> thread is happening within the hibernate-infinispan bundle, that CL instance
>> is hibernate-infinispan's BundleWiring.  If hibernate-infinispan's manifest
>> explicitly imports the package being loaded, this works fine.  But, as I
>> hit, that's not usually the case.  This stack fails when it attempted to
>> load org.infinispan.remoting.transport.jgroups.JGroupsTransport.  Adding
>> org.infinispan.remoting.transport.jgroups to our imports worked, but that's
>> not ideal.
>>
>> 2.) Reliance on TCCL.  See GlobalConfigurationBuilder#cl as an example.
>> TCCL should be avoided at all costs.  Here's an example:
>> https://gist.github.com/brmeyer/141ea83fb632dd126406.  Yes,
>> ConfigurationBuilderHolder could attempt to pass in a CL to
>> GlobalConfigurationBuilder, but we'd run into the same situation for #1.  In
>> this specific example, we're trying to load the
>> "infinispan-core-component-metadata.dat" resource within the infinispan-core
>> bundle, not visible to the hibernate-infinispan bundle CL.
>>
>> commons already has a step towards a solution: OsgiFileLookup.  However,
>> it scans over *all* bundles activated in the container.  There's certainly
>> performance issues with that, but more importantly can introduce conflicts
>> (multiple versions of Infinispan or client bundles running simultaneously, a
>> resource existing in multiple bundles, etc.).
>>
>> What we did in Hibernate was to introduce an OSGi-specific implementation
>> of ClassLoader that's aware of what bundles it needs to consider.  In
>> frameworks with multiple bundles/modules, this is definitely more
>> complicated.  For now, we limit the scope to core, entitymanager (JPA), and
>> the "requesting bundle" (the client bundle requesting the Session).  The
>> "requesting bundle" concept was important for us since we scan and rely on
>> the client bundle's entities, mapping files, etc.
>>
>> There are several routes, but all boil down to relying on OSGi APIs to use
>> Bundles to discover classes and resources, with TCCL & Class#getClassLoader
>> as a just-in-case backup.  How the scope of that Bundle set is defined is
>> largely up to the framework's existing architecture and dependency tree.
>>
>> What I might recommend as a first step would be expanding/refactoring
>> OsgiFileLookup to include loading classes, but continue to allow it to scan
>> all bundles (for now).  That will at least remove the initial CL issues.
>> But, that would need to be followed up.
>>
>> Before I keep going down the rabbit hole, just wanted to see if there were
>> any other thoughts.  I'm making general assumptions without knowing much
>> about Infinispan's architecture.  Thanks!
>>
>> Brett Meyer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List"
>> <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>> Sent: Friday, December 6, 2013 11:56:42 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>
>> Sorry, forgot the link:
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-8214
>>
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List"
>> <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>> Sent: Friday, December 6, 2013 11:51:33 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>
>> Randall, that is *definitely* the case and is certainly true for
>> Hibernate.  The work involved:
>>
>> * correctly resolving ClassLoaders based on the activated bundles
>> * supporting multiple containers and contexts (container-managed JPA,
>> un-managed JPA/native, etc.)
>> * fully supporting OSGi/Blueprint services (both for internal services as
>> well as externally-registered)
>> * bundle scanning
>> * generally working towards supporting the dynamic nature
>> * full unit-tests with Arquillian and an OSGi container
>>
>> It's a matter of holistically supporting the "OSGi way" (for better or
>> worse), as opposed to simply ensuring the library's manifest is correct.
>>
>> There were a bloody ton of gotchas and caveats I hit along the way.
>> That's more along the lines of where I might be able to help.
>>
>> I'm even more interested in this effort so that we can support
>> hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I
>> hit  ClassLoader issues [1].  Some of that may already be resolved.
>>
>> The next step may simply be giving hibernate-infinispan another shot and
>> correcting things as I find them.  In parallel, feel free to let me know if
>> there's anything else!  ORM supports lots of OSGi-enabled extension points,
>> etc. that are powerful for users, but obviously I don't have the Infinispan
>> knowledge to know what would be necessary.
>>
>> Thanks!
>>
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>>
>> ----- Original Message -----
>> From: "Randall Hauch" <rhauch at redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
>> Sent: Friday, December 6, 2013 10:57:23 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>
>> Brett, correct me if I?m wrong, but isn?t there a difference in making
>> some library *work* in an OSGi environment and making that library
>> *naturally fit well* in an OSGi-enabled application? For example, making the
>> JAR?s be OSGi bundles is easy and technically makes it possible to deploy a
>> JAR into an OSGi env, but that?s not where the payoff is. IIUC what you
>> really want is a BundleActivator or Declarative Services [1] so that the
>> library?s components are readily available in a naturally-OSGi way.
>>
>> [1]
>> http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>>
>>> + infinispan-dev
>>>
>>> Thanks for offering to look into this Brett!
>>> We're already producing OSGi bundles for our modules, but these are not
>>> tested extensively so if you'd review them and test them a bit would be
>>> great!
>>> Tristan can get you up to speed with this.
>>>
>>>
>>>>> Sanne/Galder/Pete,
>>>>>
>>>>> Random question: what's the current state of making Infinispan OSGi
>>>>> friendly?  I'm definitely interested in helping, if it's still a need.  This
>>>>> past year, I went through the exercise of making Hibernate work well in
>>>>> OSGi, so all of challenges (read: *many* of them) are still fairly fresh on
>>>>> my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>>>>
>>>>> If you're up for it, fill me in?  I'm happy to pull everything down and
>>>>> start working with it.
>>>>>
>>>>> Brett Meyer
>>>>> Software Engineer
>>>>> Red Hat, Hibernate ORM
>>>>>
>>>>
>>>
>>> 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
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>


From galder at redhat.com  Mon Dec 16 11:12:15 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Mon, 16 Dec 2013 17:12:15 +0100
Subject: [infinispan-dev] Weekly IRC meeting minutes
Message-ID: <643623D5-3004-44F6-AE57-72A13543310D@redhat.com>

This week's minutes from the IRC team meeting can be found here:
http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2013/infinispan.2013-12-16-15.05.html 

Cheers,
--
Galder Zamarre?o
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org



From bibryam at gmail.com  Tue Dec 17 17:49:17 2013
From: bibryam at gmail.com (Bilgin Ibryam)
Date: Tue, 17 Dec 2013 22:49:17 +0000
Subject: [infinispan-dev] help with Infinispan OSGi
Message-ID: <CAJ6eY0Z3tc5Ta6iWjvRiEnuyz8DjHQG3SndhcS3p3PnSqnx_LA@mail.gmail.com>

Hi guys,

some time ago I created camel-infinispan component [1] and when I tried to
deploy that on an OSGI container, all the fun began :)

You can see all the steps [2] I had to do in order to deploy Infinispan
jars on OSGI. They are far from the optimal but should give you some
pointers to things to fix while working on it.

Looking forward seeing on Infinispan on OSGI, right now it is a showstopper
for couple of POCs.


[1] http://camel.apache.org/infinispan.html
[2] https://github.com/bibryam/camel-infinispan-osgi

Cheers,

-- 
Bilgin Ibryam

Apache Camel & Apache OFBiz committer
Blog: ofbizian.com
Twitter: @bibryam <https://twitter.com/bibryam>

Author of Instant Apache Camel Message Routing
http://www.amazon.com/dp/1783283475
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131217/9b8883f1/attachment.html 

From galder at redhat.com  Wed Dec 18 08:09:10 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Wed, 18 Dec 2013 14:09:10 +0100
Subject: [infinispan-dev] Parallel M/R
In-Reply-To: <52A9F925.9080207@redhat.com>
References: <529F6374.3070901@redhat.com>	<D8A3D63D-5054-44AA-B846-BA5C53FFD94F@redhat.com>	<52A1FD24.7000007@redhat.com>
	<59C835EB-E2C6-4EA0-BB1A-DCE4F5D182DB@redhat.com>
	<52A9F925.9080207@redhat.com>
Message-ID: <9F69CC38-5E1D-467A-8E4C-56F8A95B7171@redhat.com>

Looks good, I made a comment replying to one of Mircea's comments.

Cheers,

On Dec 12, 2013, at 6:57 PM, Vladimir Blagojevic <vblagoje at redhat.com> wrote:

> On 12/6/2013, 11:40 AM, Mircea Markus wrote:
>> Hmm I think you could leverage the parallel iteration from the EquivalentConcurrentHashMapV8 there instead of writing it yourself ;)
>> 
> Hi, for those interested in parallel M/R I have uploaded my first 
> proposal that will hopefully, with your input, soon turn into a PR. A 
> couple of things to note: we do parallel iteration using JDK8 
> ConcurrentHashMap port (see DefaultDataContainer). Doing parallel 
> iteration makes sense when we have to iterate over all keys in data 
> container and check whether each individual key should be traversed 
> (using Mircea's filter). Sometimes it does not make sense to iterate 
> over all keys as input keys are provided to M/R task and input keys 
> represent only a small subset of all keys in the data container. Even in 
> those cases we do parallel execution but in a slightly different 
> approach (again see DefaultDataContainer).
> 
> Please provide feedback directly on 
> https://github.com/vblagoje/infinispan/tree/t_2284_mm or if you have 
> some general comments here on dev list.
> 
> Thanks for you feedback,
> Vladimir
> _______________________________________________
> 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



From galder at redhat.com  Wed Dec 18 08:12:20 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Wed, 18 Dec 2013 14:12:20 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <52AB1585.7030602@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<52A19CC3.40807@redhat.com>
	<C5767B2C-3507-470A-A0FE-19A2D6A102A6@redhat.com>
	<52AB1585.7030602@redhat.com>
Message-ID: <F808DE83-4CEF-48FC-923F-4419E6106376@redhat.com>


On Dec 13, 2013, at 3:11 PM, Radim Vansa <rvansa at redhat.com> wrote:

> On 12/13/2013 02:44 PM, Galder Zamarre?o wrote:
>> On Dec 6, 2013, at 10:45 AM, Radim Vansa <rvansa at 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 filtering.
>> What do you mean by runtime parameter exactly? Can you give a concrete example of what you want to achieve that is not possible with what I've written up?
> 
> As I stressed, if the client wants to listen for events on key_123456, then you can deploy a filter matching key_{number} (and additional constraints) but the 123456 is not known at deployment time.

True, that's a limitation of the current approach, but I don't see it crucial as long as we have some static filtering in place. The feature itself is already pretty large, so I'd consider this (dynamic filtering) at a later point.

> 
>> 
>>> 2) setting ack/no ack in listener, and then configuring server-wise whether you should ack each / only last event sounds weird. I'd replace the boolean with enum { NO_ACK, ACK_EACH, ACK_LAST }.
>> Makes a lot of sense, +1.
>> 
>>> 3) should the client provide source id when registering listener or when starting RemoteCacheManager? No API for that.
>> Every operation will require a source ID from now on, so clients must provide it from first operation sent to the server. From a Java client perspective, you'd have this from the start via the configuration.
>> 
>>> 4) clustered events design does not specify any means to replicating the clustered event listener - all it does is that you register the listener on one node and the other nodes then route events to this node, until the node dies/deregisters the listener. No replication. Please specify, how should it piggyback on clustered events, and how should the listener list be replicated.
>> In clustered listeners, the other nodes you talk about are gonna need to know about the clustered listeners so that they route events. Some kind of information about these clustered listeners will need to be sent around the cluster. The exact details are probably implementation details but we have a clustered registry already in place for this kind of things. In any case, it'd make a lot of sense that both use cases reuse as much as logic in this area.
> 
> OK, this is probably the desired behaviour, it just is not covered by the Clustered Events design draft. Probably something to add - I'll ping Mircea about that. And you're right that it would make a lot of sense to have shared structure for the listeners, and two implementations of the delivery boy (one to the node where a clustered event has been registered and second to local component handling HotRod clients).
> 
>> 
>>> 5) non-acked events: how exactly do you expect the ack data to be replicated, and updated? I see three options:
>>> A) Let non-acked list be a part of the listener record in replicated cache, and the primary owner which executes the event should update these via delta messages. I guess for proper reliability it should add operation record synchronously before confirming the operation to the originator, and then it might asynchronously remove it after the ack from client. When a node becomes primary owner, it should send events to client for all non-acked events.
>>> B) Having the non-acked list attached directly to cache entry (updating it together with regular backup), and then asynchronously updating the non-ack list after ack comes
>>> C) Separate cache for acks by entry keys, similar to B, consistent hash synced with the main entry cache
>> Definitely not B. I don't wanna tie the internal cache entry to the ACKs. The two should be independent. Either C or A. For C, you'd wished to have a single cache for all listeners+caches, but you'd have to think about the keys and to have the same consistent hash, you'd have to have same keys. A might be better, but you certainly don't want this ACK info in a replicated structure. You'd want ACKs in a distributed cache preferably, and clustered listener info in the clustered replicated registry.
> There already is some CH implementation which aims at sharing the same distribution for all caches, SyncConsistentHash. Is there some problem with C and forcing this for the caches? Dan?
> 
> Radim


--
Galder Zamarre?o
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org



From galder at redhat.com  Wed Dec 18 08:22:13 2013
From: galder at redhat.com (=?windows-1252?Q?Galder_Zamarre=F1o?=)
Date: Wed, 18 Dec 2013 14:22:13 +0100
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <52AF0781.7010400@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
	<2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
	<595428667.30164908.1386870900128.JavaMail.root@redhat.com>
	<52AF0781.7010400@redhat.com>
Message-ID: <7313DB94-6C42-4502-8FEA-FCFA18329218@redhat.com>


On Dec 16, 2013, at 3:00 PM, Eric Wittmann <eric.wittmann at redhat.com> wrote:

> I wanted to add that in the Overlord group we're also looking into using ISPN in OSGi.  Our directive is to get our projects running in Fuse 6.1.
> 
> To that end I've been working on getting Overlord:S-RAMP up and running, which requires both ModeShape and ISPN.
> 
> Additionally, Gary Brown uses ISPN in Overlord:RTGov and so will need to get it working directly (no ModeShape) in Fuse 6.1.
> 
> I've made some progress on my end but have run into some of the same issues as Brett.
> 
> An additional issue I hit was the use of Java's ServiceLoader for org.infinispan.configuration.parsing.ConfigurationParser.  None of the parsers get loaded because ServiceLoader doesn't work particularly well in OSGi.  We had this same issue in S-RAMP (we use ServiceLoader in a few places).  I solved it by using the OSGi Service Registry when running in an OSGi container, but continuing to use ServiceLoader otherwise.

^ Can you add a JIRA for this so that we can abstract this away? I'm not sure how exactly we'd decide on the impl to use. By default it'd be SL impl. When used on OSGI though, an alternative service loading impl would need to be configured specifically by the user? Or would Infinispan itself detect that it's in OSGi and hence used the corresponding impl? I've no idea about OSGI.

> In any case - I was wondering if anyone thought it might be a good idea to create a git repo where we can create some test OSGi applications that use ISPN and can be deployed (e.g. to Fuse).  This would be for testing purposes only - to shake out problems.  Might be useful for collaboration?

A quickstart on [1] would be the perfect place for something like that, i.e. fuse + infinispan or something like that.

[1] http://www.jboss.org/jdf/quickstarts/get-started/

> 
> -Eric
> 
> 
> On 12/12/2013 12:55 PM, Brett Meyer wrote:
>> I finally had a chance to start working with this, a bit, today.  Here's what I've found so far.
>> 
>> In general, I'm seeing 2 types of CL issues come up when testing w/ hibernate-infinispan:
>> 
>> 1.) Reliance on the client bundle's CL.  Take the following stack as an example: https://gist.github.com/brmeyer/c8aaa1157a4a951a462c.  Hibernate's InfinispanRegionFactory is building a ConfigurationBuilderHolder.  Parser60#parseTransport eventually gives the ConfigurationBuilderHolder#getClassLoader to Util#loadClass.  But since this thread is happening within the hibernate-infinispan bundle, that CL instance is hibernate-infinispan's BundleWiring.  If hibernate-infinispan's manifest explicitly imports the package being loaded, this works fine.  But, as I hit, that's not usually the case.  This stack fails when it attempted to load org.infinispan.remoting.transport.jgroups.JGroupsTransport.  Adding org.infinispan.remoting.transport.jgroups to our imports worked, but that's not ideal.
>> 
>> 2.) Reliance on TCCL.  See GlobalConfigurationBuilder#cl as an example.  TCCL should be avoided at all costs.  Here's an example: https://gist.github.com/brmeyer/141ea83fb632dd126406.  Yes, ConfigurationBuilderHolder could attempt to pass in a CL to GlobalConfigurationBuilder, but we'd run into the same situation for #1.  In this specific example, we're trying to load the "infinispan-core-component-metadata.dat" resource within the infinispan-core bundle, not visible to the hibernate-infinispan bundle CL.
>> 
>> commons already has a step towards a solution: OsgiFileLookup.  However, it scans over *all* bundles activated in the container.  There's certainly performance issues with that, but more importantly can introduce conflicts (multiple versions of Infinispan or client bundles running simultaneously, a resource existing in multiple bundles, etc.).
>> 
>> What we did in Hibernate was to introduce an OSGi-specific implementation of ClassLoader that's aware of what bundles it needs to consider.  In frameworks with multiple bundles/modules, this is definitely more complicated.  For now, we limit the scope to core, entitymanager (JPA), and the "requesting bundle" (the client bundle requesting the Session).  The "requesting bundle" concept was important for us since we scan and rely on the client bundle's entities, mapping files, etc.
>> 
>> There are several routes, but all boil down to relying on OSGi APIs to use Bundles to discover classes and resources, with TCCL & Class#getClassLoader as a just-in-case backup.  How the scope of that Bundle set is defined is largely up to the framework's existing architecture and dependency tree.
>> 
>> What I might recommend as a first step would be expanding/refactoring OsgiFileLookup to include loading classes, but continue to allow it to scan all bundles (for now).  That will at least remove the initial CL issues.  But, that would need to be followed up.
>> 
>> Before I keep going down the rabbit hole, just wanted to see if there were any other thoughts.  I'm making general assumptions without knowing much about Infinispan's architecture.  Thanks!
>> 
>> Brett Meyer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>> Sent: Friday, December 6, 2013 11:56:42 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>> 
>> Sorry, forgot the link:
>> 
>> [1] https://hibernate.atlassian.net/browse/HHH-8214
>> 
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>> Sent: Friday, December 6, 2013 11:51:33 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>> 
>> Randall, that is *definitely* the case and is certainly true for Hibernate.  The work involved:
>> 
>> * correctly resolving ClassLoaders based on the activated bundles
>> * supporting multiple containers and contexts (container-managed JPA, un-managed JPA/native, etc.)
>> * fully supporting OSGi/Blueprint services (both for internal services as well as externally-registered)
>> * bundle scanning
>> * generally working towards supporting the dynamic nature
>> * full unit-tests with Arquillian and an OSGi container
>> 
>> It's a matter of holistically supporting the "OSGi way" (for better or worse), as opposed to simply ensuring the library's manifest is correct.
>> 
>> There were a bloody ton of gotchas and caveats I hit along the way.  That's more along the lines of where I might be able to help.
>> 
>> I'm even more interested in this effort so that we can support hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I hit  ClassLoader issues [1].  Some of that may already be resolved.
>> 
>> The next step may simply be giving hibernate-infinispan another shot and correcting things as I find them.  In parallel, feel free to let me know if there's anything else!  ORM supports lots of OSGi-enabled extension points, etc. that are powerful for users, but obviously I don't have the Infinispan knowledge to know what would be necessary.
>> 
>> Thanks!
>> 
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Randall Hauch" <rhauch at redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
>> Sent: Friday, December 6, 2013 10:57:23 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>> 
>> Brett, correct me if I?m wrong, but isn?t there a difference in making some library *work* in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled application? For example, making the JAR?s be OSGi bundles is easy and technically makes it possible to deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC what you really want is a BundleActivator or Declarative Services [1] so that the library?s components are readily available in a naturally-OSGi way.
>> 
>> [1] http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html
>> 
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>>> + infinispan-dev
>>> 
>>> Thanks for offering to look into this Brett!
>>> We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
>>> Tristan can get you up to speed with this.
>>> 
>>> 
>>>>> Sanne/Galder/Pete,
>>>>> 
>>>>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>>>> 
>>>>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>>>>> 
>>>>> Brett Meyer
>>>>> Software Engineer
>>>>> Red Hat, Hibernate ORM
>>>>> 
>>>> 
>>> 
>>> 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
>> 
>> 
>> _______________________________________________
>> 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



From galder at redhat.com  Wed Dec 18 08:22:47 2013
From: galder at redhat.com (=?windows-1252?Q?Galder_Zamarre=F1o?=)
Date: Wed, 18 Dec 2013 14:22:47 +0100
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <CAFm4XO2W0MiDYw=8cbXPJ9_xo3r=4ZPK_miHNRCaLs3EB21Y7w@mail.gmail.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<17A795E4-5FF0-4A91-9C93-CC2BDCEAED13@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
	<2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
	<595428667.30164908.1386870900128.JavaMail.root@redhat.com>
	<52AF0781.7010400@redhat.com>
	<CAFm4XO2W0MiDYw=8cbXPJ9_xo3r=4ZPK_miHNRCaLs3EB21Y7w@mail.gmail.com>
Message-ID: <03BF1C23-2509-44AB-83D5-6F6727EBA3F0@redhat.com>


On Dec 16, 2013, at 4:08 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Eric,
> thanks that sounds great, having a solid collection of tests is
> probably the most usefull specification for what we need to achieve.
> 
> @Infinispan team: could we add such tests in the Infinispan
> repository? I think that's where they belong.

Apart from the quickstart, I agree that some unit tests would be great too and we'd welcome them ;)

> 
> Sanne
> 
> On 16 December 2013 14:00, Eric Wittmann <eric.wittmann at redhat.com> wrote:
>> I wanted to add that in the Overlord group we're also looking into using
>> ISPN in OSGi.  Our directive is to get our projects running in Fuse 6.1.
>> 
>> To that end I've been working on getting Overlord:S-RAMP up and running,
>> which requires both ModeShape and ISPN.
>> 
>> Additionally, Gary Brown uses ISPN in Overlord:RTGov and so will need to get
>> it working directly (no ModeShape) in Fuse 6.1.
>> 
>> I've made some progress on my end but have run into some of the same issues
>> as Brett.
>> 
>> An additional issue I hit was the use of Java's ServiceLoader for
>> org.infinispan.configuration.parsing.ConfigurationParser.  None of the
>> parsers get loaded because ServiceLoader doesn't work particularly well in
>> OSGi.  We had this same issue in S-RAMP (we use ServiceLoader in a few
>> places).  I solved it by using the OSGi Service Registry when running in an
>> OSGi container, but continuing to use ServiceLoader otherwise.
>> 
>> In any case - I was wondering if anyone thought it might be a good idea to
>> create a git repo where we can create some test OSGi applications that use
>> ISPN and can be deployed (e.g. to Fuse).  This would be for testing purposes
>> only - to shake out problems.  Might be useful for collaboration?
>> 
>> -Eric
>> 
>> 
>> 
>> On 12/12/2013 12:55 PM, Brett Meyer wrote:
>>> 
>>> I finally had a chance to start working with this, a bit, today.  Here's
>>> what I've found so far.
>>> 
>>> In general, I'm seeing 2 types of CL issues come up when testing w/
>>> hibernate-infinispan:
>>> 
>>> 1.) Reliance on the client bundle's CL.  Take the following stack as an
>>> example: https://gist.github.com/brmeyer/c8aaa1157a4a951a462c.  Hibernate's
>>> InfinispanRegionFactory is building a ConfigurationBuilderHolder.
>>> Parser60#parseTransport eventually gives the
>>> ConfigurationBuilderHolder#getClassLoader to Util#loadClass.  But since this
>>> thread is happening within the hibernate-infinispan bundle, that CL instance
>>> is hibernate-infinispan's BundleWiring.  If hibernate-infinispan's manifest
>>> explicitly imports the package being loaded, this works fine.  But, as I
>>> hit, that's not usually the case.  This stack fails when it attempted to
>>> load org.infinispan.remoting.transport.jgroups.JGroupsTransport.  Adding
>>> org.infinispan.remoting.transport.jgroups to our imports worked, but that's
>>> not ideal.
>>> 
>>> 2.) Reliance on TCCL.  See GlobalConfigurationBuilder#cl as an example.
>>> TCCL should be avoided at all costs.  Here's an example:
>>> https://gist.github.com/brmeyer/141ea83fb632dd126406.  Yes,
>>> ConfigurationBuilderHolder could attempt to pass in a CL to
>>> GlobalConfigurationBuilder, but we'd run into the same situation for #1.  In
>>> this specific example, we're trying to load the
>>> "infinispan-core-component-metadata.dat" resource within the infinispan-core
>>> bundle, not visible to the hibernate-infinispan bundle CL.
>>> 
>>> commons already has a step towards a solution: OsgiFileLookup.  However,
>>> it scans over *all* bundles activated in the container.  There's certainly
>>> performance issues with that, but more importantly can introduce conflicts
>>> (multiple versions of Infinispan or client bundles running simultaneously, a
>>> resource existing in multiple bundles, etc.).
>>> 
>>> What we did in Hibernate was to introduce an OSGi-specific implementation
>>> of ClassLoader that's aware of what bundles it needs to consider.  In
>>> frameworks with multiple bundles/modules, this is definitely more
>>> complicated.  For now, we limit the scope to core, entitymanager (JPA), and
>>> the "requesting bundle" (the client bundle requesting the Session).  The
>>> "requesting bundle" concept was important for us since we scan and rely on
>>> the client bundle's entities, mapping files, etc.
>>> 
>>> There are several routes, but all boil down to relying on OSGi APIs to use
>>> Bundles to discover classes and resources, with TCCL & Class#getClassLoader
>>> as a just-in-case backup.  How the scope of that Bundle set is defined is
>>> largely up to the framework's existing architecture and dependency tree.
>>> 
>>> What I might recommend as a first step would be expanding/refactoring
>>> OsgiFileLookup to include loading classes, but continue to allow it to scan
>>> all bundles (for now).  That will at least remove the initial CL issues.
>>> But, that would need to be followed up.
>>> 
>>> Before I keep going down the rabbit hole, just wanted to see if there were
>>> any other thoughts.  I'm making general assumptions without knowing much
>>> about Infinispan's architecture.  Thanks!
>>> 
>>> Brett Meyer
>>> Red Hat, Hibernate ORM
>>> 
>>> ----- Original Message -----
>>> From: "Brett Meyer" <brmeyer at redhat.com>
>>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List"
>>> <infinispan-dev at lists.jboss.org>
>>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>>> Sent: Friday, December 6, 2013 11:56:42 AM
>>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>> 
>>> Sorry, forgot the link:
>>> 
>>> [1] https://hibernate.atlassian.net/browse/HHH-8214
>>> 
>>> Brett Meyer
>>> Software Engineer
>>> Red Hat, Hibernate ORM
>>> 
>>> ----- Original Message -----
>>> From: "Brett Meyer" <brmeyer at redhat.com>
>>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List"
>>> <infinispan-dev at lists.jboss.org>
>>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>>> Sent: Friday, December 6, 2013 11:51:33 AM
>>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>> 
>>> Randall, that is *definitely* the case and is certainly true for
>>> Hibernate.  The work involved:
>>> 
>>> * correctly resolving ClassLoaders based on the activated bundles
>>> * supporting multiple containers and contexts (container-managed JPA,
>>> un-managed JPA/native, etc.)
>>> * fully supporting OSGi/Blueprint services (both for internal services as
>>> well as externally-registered)
>>> * bundle scanning
>>> * generally working towards supporting the dynamic nature
>>> * full unit-tests with Arquillian and an OSGi container
>>> 
>>> It's a matter of holistically supporting the "OSGi way" (for better or
>>> worse), as opposed to simply ensuring the library's manifest is correct.
>>> 
>>> There were a bloody ton of gotchas and caveats I hit along the way.
>>> That's more along the lines of where I might be able to help.
>>> 
>>> I'm even more interested in this effort so that we can support
>>> hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I
>>> hit  ClassLoader issues [1].  Some of that may already be resolved.
>>> 
>>> The next step may simply be giving hibernate-infinispan another shot and
>>> correcting things as I find them.  In parallel, feel free to let me know if
>>> there's anything else!  ORM supports lots of OSGi-enabled extension points,
>>> etc. that are powerful for users, but obviously I don't have the Infinispan
>>> knowledge to know what would be necessary.
>>> 
>>> Thanks!
>>> 
>>> Brett Meyer
>>> Software Engineer
>>> Red Hat, Hibernate ORM
>>> 
>>> ----- Original Message -----
>>> From: "Randall Hauch" <rhauch at redhat.com>
>>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>>> Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
>>> Sent: Friday, December 6, 2013 10:57:23 AM
>>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>>> 
>>> Brett, correct me if I?m wrong, but isn?t there a difference in making
>>> some library *work* in an OSGi environment and making that library
>>> *naturally fit well* in an OSGi-enabled application? For example, making the
>>> JAR?s be OSGi bundles is easy and technically makes it possible to deploy a
>>> JAR into an OSGi env, but that?s not where the payoff is. IIUC what you
>>> really want is a BundleActivator or Declarative Services [1] so that the
>>> library?s components are readily available in a naturally-OSGi way.
>>> 
>>> [1]
>>> http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html
>>> 
>>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>>> 
>>>> + infinispan-dev
>>>> 
>>>> Thanks for offering to look into this Brett!
>>>> We're already producing OSGi bundles for our modules, but these are not
>>>> tested extensively so if you'd review them and test them a bit would be
>>>> great!
>>>> Tristan can get you up to speed with this.
>>>> 
>>>> 
>>>>>> Sanne/Galder/Pete,
>>>>>> 
>>>>>> Random question: what's the current state of making Infinispan OSGi
>>>>>> friendly?  I'm definitely interested in helping, if it's still a need.  This
>>>>>> past year, I went through the exercise of making Hibernate work well in
>>>>>> OSGi, so all of challenges (read: *many* of them) are still fairly fresh on
>>>>>> my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>>>>> 
>>>>>> If you're up for it, fill me in?  I'm happy to pull everything down and
>>>>>> start working with it.
>>>>>> 
>>>>>> Brett Meyer
>>>>>> Software Engineer
>>>>>> Red Hat, Hibernate ORM
>>>>>> 
>>>>> 
>>>> 
>>>> 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
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>> 
> 
> _______________________________________________
> 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



From sanne at infinispan.org  Wed Dec 18 09:13:34 2013
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 18 Dec 2013 14:13:34 +0000
Subject: [infinispan-dev] New 6.0.1 release
Message-ID: <CAFm4XO3FR9xvAcOADfHySWBhL+x0aCNA2y0tfAOJGnPR=vfTdA@mail.gmail.com>

I don't get it, don't we announce releases anymore?

I guess not every release necessary requires a blog post, but it would be
good at least to receive a heads up on this list.

Sanne


---------- Forwarded message ----------
From: artifact listener <noreply at openwide.fr>
Date: 18 December 2013 13:45
Subject: [artifact listener] New releases - 2013-12-18


  artifact listener  New releases - 2013-12-18

New releases have been deployed on Maven Central.
  GroupId  ArtifactId  Version    org.infinispan  infinispan-core
<https://www.artifact-listener.org/artifact/org.infinispan/infinispan-core/>
6.0.1.Final   org.infinispan  infinispan-lucene-directory
<https://www.artifact-listener.org/artifact/org.infinispan/infinispan-lucene-directory/>
6.0.1.Final
 If you want to configure your notifications, sign in and change your
settings on artifact listener <https://www.artifact-listener.org/profile/>.
 About this service <https://www.artifact-listener.org/about/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131218/63858f7d/attachment.html 

From brmeyer at redhat.com  Wed Dec 18 09:24:19 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 18 Dec 2013 09:24:19 -0500 (EST)
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <7313DB94-6C42-4502-8FEA-FCFA18329218@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<E8EFDF3A-67C1-4D6C-A7FE-B4441F2CE2ED@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
	<2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
	<595428667.30164908.1386870900128.JavaMail.root@redhat.com>
	<52AF0781.7010400@redhat.com>
	<7313DB94-6C42-4502-8FEA-FCFA18329218@redhat.com>
Message-ID: <1712180701.34450541.1387376659632.JavaMail.root@redhat.com>

Galder, ConfigurationParser/CL/ServiceLoader/etc. is a part of what I already have cooking in my fork.  When finished, want everything in a combined PR against ISPN-800, or would you rather have something more granular?

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Galder Zamarre?o" <galder at redhat.com>
To: "Eric Wittmann" <eric.wittmann at redhat.com>
Cc: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>, "Brett Meyer" <brmeyer at redhat.com>, "Sanne Grinovero" <sanne at hibernate.org>, "Pete Muir" <pmuir at redhat.com>, "Randall Hauch" <rhauch at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
Sent: Wednesday, December 18, 2013 8:22:13 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi


On Dec 16, 2013, at 3:00 PM, Eric Wittmann <eric.wittmann at redhat.com> wrote:

> I wanted to add that in the Overlord group we're also looking into using ISPN in OSGi.  Our directive is to get our projects running in Fuse 6.1.
> 
> To that end I've been working on getting Overlord:S-RAMP up and running, which requires both ModeShape and ISPN.
> 
> Additionally, Gary Brown uses ISPN in Overlord:RTGov and so will need to get it working directly (no ModeShape) in Fuse 6.1.
> 
> I've made some progress on my end but have run into some of the same issues as Brett.
> 
> An additional issue I hit was the use of Java's ServiceLoader for org.infinispan.configuration.parsing.ConfigurationParser.  None of the parsers get loaded because ServiceLoader doesn't work particularly well in OSGi.  We had this same issue in S-RAMP (we use ServiceLoader in a few places).  I solved it by using the OSGi Service Registry when running in an OSGi container, but continuing to use ServiceLoader otherwise.

^ Can you add a JIRA for this so that we can abstract this away? I'm not sure how exactly we'd decide on the impl to use. By default it'd be SL impl. When used on OSGI though, an alternative service loading impl would need to be configured specifically by the user? Or would Infinispan itself detect that it's in OSGi and hence used the corresponding impl? I've no idea about OSGI.

> In any case - I was wondering if anyone thought it might be a good idea to create a git repo where we can create some test OSGi applications that use ISPN and can be deployed (e.g. to Fuse).  This would be for testing purposes only - to shake out problems.  Might be useful for collaboration?

A quickstart on [1] would be the perfect place for something like that, i.e. fuse + infinispan or something like that.

[1] http://www.jboss.org/jdf/quickstarts/get-started/

> 
> -Eric
> 
> 
> On 12/12/2013 12:55 PM, Brett Meyer wrote:
>> I finally had a chance to start working with this, a bit, today.  Here's what I've found so far.
>> 
>> In general, I'm seeing 2 types of CL issues come up when testing w/ hibernate-infinispan:
>> 
>> 1.) Reliance on the client bundle's CL.  Take the following stack as an example: https://gist.github.com/brmeyer/c8aaa1157a4a951a462c.  Hibernate's InfinispanRegionFactory is building a ConfigurationBuilderHolder.  Parser60#parseTransport eventually gives the ConfigurationBuilderHolder#getClassLoader to Util#loadClass.  But since this thread is happening within the hibernate-infinispan bundle, that CL instance is hibernate-infinispan's BundleWiring.  If hibernate-infinispan's manifest explicitly imports the package being loaded, this works fine.  But, as I hit, that's not usually the case.  This stack fails when it attempted to load org.infinispan.remoting.transport.jgroups.JGroupsTransport.  Adding org.infinispan.remoting.transport.jgroups to our imports worked, but that's not ideal.
>> 
>> 2.) Reliance on TCCL.  See GlobalConfigurationBuilder#cl as an example.  TCCL should be avoided at all costs.  Here's an example: https://gist.github.com/brmeyer/141ea83fb632dd126406.  Yes, ConfigurationBuilderHolder could attempt to pass in a CL to GlobalConfigurationBuilder, but we'd run into the same situation for #1.  In this specific example, we're trying to load the "infinispan-core-component-metadata.dat" resource within the infinispan-core bundle, not visible to the hibernate-infinispan bundle CL.
>> 
>> commons already has a step towards a solution: OsgiFileLookup.  However, it scans over *all* bundles activated in the container.  There's certainly performance issues with that, but more importantly can introduce conflicts (multiple versions of Infinispan or client bundles running simultaneously, a resource existing in multiple bundles, etc.).
>> 
>> What we did in Hibernate was to introduce an OSGi-specific implementation of ClassLoader that's aware of what bundles it needs to consider.  In frameworks with multiple bundles/modules, this is definitely more complicated.  For now, we limit the scope to core, entitymanager (JPA), and the "requesting bundle" (the client bundle requesting the Session).  The "requesting bundle" concept was important for us since we scan and rely on the client bundle's entities, mapping files, etc.
>> 
>> There are several routes, but all boil down to relying on OSGi APIs to use Bundles to discover classes and resources, with TCCL & Class#getClassLoader as a just-in-case backup.  How the scope of that Bundle set is defined is largely up to the framework's existing architecture and dependency tree.
>> 
>> What I might recommend as a first step would be expanding/refactoring OsgiFileLookup to include loading classes, but continue to allow it to scan all bundles (for now).  That will at least remove the initial CL issues.  But, that would need to be followed up.
>> 
>> Before I keep going down the rabbit hole, just wanted to see if there were any other thoughts.  I'm making general assumptions without knowing much about Infinispan's architecture.  Thanks!
>> 
>> Brett Meyer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>> Sent: Friday, December 6, 2013 11:56:42 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>> 
>> Sorry, forgot the link:
>> 
>> [1] https://hibernate.atlassian.net/browse/HHH-8214
>> 
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>> Sent: Friday, December 6, 2013 11:51:33 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>> 
>> Randall, that is *definitely* the case and is certainly true for Hibernate.  The work involved:
>> 
>> * correctly resolving ClassLoaders based on the activated bundles
>> * supporting multiple containers and contexts (container-managed JPA, un-managed JPA/native, etc.)
>> * fully supporting OSGi/Blueprint services (both for internal services as well as externally-registered)
>> * bundle scanning
>> * generally working towards supporting the dynamic nature
>> * full unit-tests with Arquillian and an OSGi container
>> 
>> It's a matter of holistically supporting the "OSGi way" (for better or worse), as opposed to simply ensuring the library's manifest is correct.
>> 
>> There were a bloody ton of gotchas and caveats I hit along the way.  That's more along the lines of where I might be able to help.
>> 
>> I'm even more interested in this effort so that we can support hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I hit  ClassLoader issues [1].  Some of that may already be resolved.
>> 
>> The next step may simply be giving hibernate-infinispan another shot and correcting things as I find them.  In parallel, feel free to let me know if there's anything else!  ORM supports lots of OSGi-enabled extension points, etc. that are powerful for users, but obviously I don't have the Infinispan knowledge to know what would be necessary.
>> 
>> Thanks!
>> 
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Randall Hauch" <rhauch at redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
>> Sent: Friday, December 6, 2013 10:57:23 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>> 
>> Brett, correct me if I?m wrong, but isn?t there a difference in making some library *work* in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled application? For example, making the JAR?s be OSGi bundles is easy and technically makes it possible to deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC what you really want is a BundleActivator or Declarative Services [1] so that the library?s components are readily available in a naturally-OSGi way.
>> 
>> [1] http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html
>> 
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>>> + infinispan-dev
>>> 
>>> Thanks for offering to look into this Brett!
>>> We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
>>> Tristan can get you up to speed with this.
>>> 
>>> 
>>>>> Sanne/Galder/Pete,
>>>>> 
>>>>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>>>> 
>>>>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>>>>> 
>>>>> Brett Meyer
>>>>> Software Engineer
>>>>> Red Hat, Hibernate ORM
>>>>> 
>>>> 
>>> 
>>> 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
>> 
>> 
>> _______________________________________________
>> 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



From sanne at infinispan.org  Wed Dec 18 10:40:30 2013
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 18 Dec 2013 15:40:30 +0000
Subject: [infinispan-dev] manual eviction and indexing
In-Reply-To: <52A88009.40108@redhat.com>
References: <CAFm4XO0b_47dJwW1jLfzo1noYW8NpE=Rzrpy8KxBgJ1mE+xUxg@mail.gmail.com>
	<52A88009.40108@redhat.com>
Message-ID: <CAFm4XO0CdPkioLubMGspaptc-hJz7_vhxCEJAU903WFPu_jEdA@mail.gmail.com>

On 11 December 2013 15:08, Adrian Nistor <anistor at redhat.com> wrote:
> I Agree. If  indexing + (automatic) eviction + no cachestore is currently
> allowed, then we should add a jira to add this config validation.
>
> But what about manual eviction? Would it make sense to handle it the way I
> did?

Generally speaking I think you're on the right direction, but I'm not
sure how solid it is to rely on a "boolean usingStores" field.

Flag usage would make it more complex, but ok let's forget about
people trying to shoot themselves as that's hopeless.

Flags aside, we also have the case of CacheStore instances being added
on the fly (not sure if that was ever implemented, but for sure there
where good reasons and we opened JIRAs to make it possible), and we
have the quite common scenario in which a CacheStore is implemented as
"selective", i.e. it only stores a specific kind of types. For example
the JPACacheStore and the Lucene Directory Cachestore themselves.. the
latter only persists elements it recognizes as lucene index segments,
and it's useful for people who want to store the indexed data and the
index itself in the same cache.
Trying to check what kind of CacheStore you have is also a slippery
slope as you could have multiple chained ones.

Generally speaking I don't think it makes sense to use manual eviction
to get the effect of a remove, if you have your data indexed and there
is a cachestore. In such cases an eviction is not removing data, so it
should not cleanup any index. If the user wants to remove data, he
should use the remove method.

Should we add a configuration attribute to the indexing element, to
allow for "remove on eviction" ?
I hate adding more configuration elements, but I think making this
behavior explicitly defined is the least confusing option. Principle
of least astonishment.

Sanne


>
>
> On 12/11/2013 02:32 PM, Sanne Grinovero wrote:
>>
>> Hi Adrian,
>> +1 good catch.
>>
>> but what's a realistic use case for {indexing + eviction + no cachestore}
>> ?
>> I guess some use cases might exist but I don't think it's critical,
>> would you agree?
>>
>> and what about automatic eviction?
>>
>> I think the guiding principle should be that if an entry can be
>> retrieved by key it should be searchable, and vice-versa, if I can
>> find it by running a query I should be able to load the result.
>> So expiry and other forms of eviction should also be considered, but
>> if there is no practical use case we can consider making this an
>> illegal configuration or simply log a warning about the particular
>> configuration.
>>
>> Sanne
>>
>> ----- Original Message -----
>>>
>>> Hi Sanne,
>>>
>>> I found that manual eviction does not update the index. I think manual
>>> eviction should behave like a remove, if there are no cache stores
>>> configured.
>>>
>>> Here's a test and a 'fix' :)
>>> https://github.com/anistor/infinispan/tree/t_manual_evict_and_indexing
>>>
>>> Let's discuss this when you have time.
>>>
>>> There is also the more complex situation of in-DataContainer eviction ...
>>>
>

From brmeyer at redhat.com  Wed Dec 18 11:05:33 2013
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 18 Dec 2013 11:05:33 -0500 (EST)
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <1712180701.34450541.1387376659632.JavaMail.root@redhat.com>
References: <1953691887.24945507.1386275697958.JavaMail.root@redhat.com>
	<05D6A159-2E02-462A-AFB7-47DC3914CB02@redhat.com>
	<1378853890.25611986.1386348693503.JavaMail.root@redhat.com>
	<2084410860.25622457.1386349002612.JavaMail.root@redhat.com>
	<595428667.30164908.1386870900128.JavaMail.root@redhat.com>
	<52AF0781.7010400@redhat.com>
	<7313DB94-6C42-4502-8FEA-FCFA18329218@redhat.com>
	<1712180701.34450541.1387376659632.JavaMail.root@redhat.com>
Message-ID: <1327817946.34566795.1387382733782.JavaMail.root@redhat.com>

After discussing several issues with Galder, I'm breaking everything down into subtasks on ISPN-800.  Feel free to comment!

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Brett Meyer" <brmeyer at redhat.com>
To: "Galder Zamarre?o" <galder at redhat.com>
Cc: "Eric Wittmann" <eric.wittmann at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>, "Sanne Grinovero" <sanne at hibernate.org>, "Pete Muir" <pmuir at redhat.com>, "Randall Hauch" <rhauch at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
Sent: Wednesday, December 18, 2013 9:24:19 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi

Galder, ConfigurationParser/CL/ServiceLoader/etc. is a part of what I already have cooking in my fork.  When finished, want everything in a combined PR against ISPN-800, or would you rather have something more granular?

Brett Meyer
Red Hat, Hibernate ORM

----- Original Message -----
From: "Galder Zamarre?o" <galder at redhat.com>
To: "Eric Wittmann" <eric.wittmann at redhat.com>
Cc: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>, "Brett Meyer" <brmeyer at redhat.com>, "Sanne Grinovero" <sanne at hibernate.org>, "Pete Muir" <pmuir at redhat.com>, "Randall Hauch" <rhauch at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
Sent: Wednesday, December 18, 2013 8:22:13 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi


On Dec 16, 2013, at 3:00 PM, Eric Wittmann <eric.wittmann at redhat.com> wrote:

> I wanted to add that in the Overlord group we're also looking into using ISPN in OSGi.  Our directive is to get our projects running in Fuse 6.1.
> 
> To that end I've been working on getting Overlord:S-RAMP up and running, which requires both ModeShape and ISPN.
> 
> Additionally, Gary Brown uses ISPN in Overlord:RTGov and so will need to get it working directly (no ModeShape) in Fuse 6.1.
> 
> I've made some progress on my end but have run into some of the same issues as Brett.
> 
> An additional issue I hit was the use of Java's ServiceLoader for org.infinispan.configuration.parsing.ConfigurationParser.  None of the parsers get loaded because ServiceLoader doesn't work particularly well in OSGi.  We had this same issue in S-RAMP (we use ServiceLoader in a few places).  I solved it by using the OSGi Service Registry when running in an OSGi container, but continuing to use ServiceLoader otherwise.

^ Can you add a JIRA for this so that we can abstract this away? I'm not sure how exactly we'd decide on the impl to use. By default it'd be SL impl. When used on OSGI though, an alternative service loading impl would need to be configured specifically by the user? Or would Infinispan itself detect that it's in OSGi and hence used the corresponding impl? I've no idea about OSGI.

> In any case - I was wondering if anyone thought it might be a good idea to create a git repo where we can create some test OSGi applications that use ISPN and can be deployed (e.g. to Fuse).  This would be for testing purposes only - to shake out problems.  Might be useful for collaboration?

A quickstart on [1] would be the perfect place for something like that, i.e. fuse + infinispan or something like that.

[1] http://www.jboss.org/jdf/quickstarts/get-started/

> 
> -Eric
> 
> 
> On 12/12/2013 12:55 PM, Brett Meyer wrote:
>> I finally had a chance to start working with this, a bit, today.  Here's what I've found so far.
>> 
>> In general, I'm seeing 2 types of CL issues come up when testing w/ hibernate-infinispan:
>> 
>> 1.) Reliance on the client bundle's CL.  Take the following stack as an example: https://gist.github.com/brmeyer/c8aaa1157a4a951a462c.  Hibernate's InfinispanRegionFactory is building a ConfigurationBuilderHolder.  Parser60#parseTransport eventually gives the ConfigurationBuilderHolder#getClassLoader to Util#loadClass.  But since this thread is happening within the hibernate-infinispan bundle, that CL instance is hibernate-infinispan's BundleWiring.  If hibernate-infinispan's manifest explicitly imports the package being loaded, this works fine.  But, as I hit, that's not usually the case.  This stack fails when it attempted to load org.infinispan.remoting.transport.jgroups.JGroupsTransport.  Adding org.infinispan.remoting.transport.jgroups to our imports worked, but that's not ideal.
>> 
>> 2.) Reliance on TCCL.  See GlobalConfigurationBuilder#cl as an example.  TCCL should be avoided at all costs.  Here's an example: https://gist.github.com/brmeyer/141ea83fb632dd126406.  Yes, ConfigurationBuilderHolder could attempt to pass in a CL to GlobalConfigurationBuilder, but we'd run into the same situation for #1.  In this specific example, we're trying to load the "infinispan-core-component-metadata.dat" resource within the infinispan-core bundle, not visible to the hibernate-infinispan bundle CL.
>> 
>> commons already has a step towards a solution: OsgiFileLookup.  However, it scans over *all* bundles activated in the container.  There's certainly performance issues with that, but more importantly can introduce conflicts (multiple versions of Infinispan or client bundles running simultaneously, a resource existing in multiple bundles, etc.).
>> 
>> What we did in Hibernate was to introduce an OSGi-specific implementation of ClassLoader that's aware of what bundles it needs to consider.  In frameworks with multiple bundles/modules, this is definitely more complicated.  For now, we limit the scope to core, entitymanager (JPA), and the "requesting bundle" (the client bundle requesting the Session).  The "requesting bundle" concept was important for us since we scan and rely on the client bundle's entities, mapping files, etc.
>> 
>> There are several routes, but all boil down to relying on OSGi APIs to use Bundles to discover classes and resources, with TCCL & Class#getClassLoader as a just-in-case backup.  How the scope of that Bundle set is defined is largely up to the framework's existing architecture and dependency tree.
>> 
>> What I might recommend as a first step would be expanding/refactoring OsgiFileLookup to include loading classes, but continue to allow it to scan all bundles (for now).  That will at least remove the initial CL issues.  But, that would need to be followed up.
>> 
>> Before I keep going down the rabbit hole, just wanted to see if there were any other thoughts.  I'm making general assumptions without knowing much about Infinispan's architecture.  Thanks!
>> 
>> Brett Meyer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>> Sent: Friday, December 6, 2013 11:56:42 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>> 
>> Sorry, forgot the link:
>> 
>> [1] https://hibernate.atlassian.net/browse/HHH-8214
>> 
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Brett Meyer" <brmeyer at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at redhat.com>
>> Sent: Friday, December 6, 2013 11:51:33 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>> 
>> Randall, that is *definitely* the case and is certainly true for Hibernate.  The work involved:
>> 
>> * correctly resolving ClassLoaders based on the activated bundles
>> * supporting multiple containers and contexts (container-managed JPA, un-managed JPA/native, etc.)
>> * fully supporting OSGi/Blueprint services (both for internal services as well as externally-registered)
>> * bundle scanning
>> * generally working towards supporting the dynamic nature
>> * full unit-tests with Arquillian and an OSGi container
>> 
>> It's a matter of holistically supporting the "OSGi way" (for better or worse), as opposed to simply ensuring the library's manifest is correct.
>> 
>> There were a bloody ton of gotchas and caveats I hit along the way.  That's more along the lines of where I might be able to help.
>> 
>> I'm even more interested in this effort so that we can support hibernate-infinispan 2nd level caching within ORM.  On the first attempt, I hit  ClassLoader issues [1].  Some of that may already be resolved.
>> 
>> The next step may simply be giving hibernate-infinispan another shot and correcting things as I find them.  In parallel, feel free to let me know if there's anything else!  ORM supports lots of OSGi-enabled extension points, etc. that are powerful for users, but obviously I don't have the Infinispan knowledge to know what would be necessary.
>> 
>> Thanks!
>> 
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>> 
>> ----- Original Message -----
>> From: "Randall Hauch" <rhauch at redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at redhat.com>
>> Sent: Friday, December 6, 2013 10:57:23 AM
>> Subject: Re: [infinispan-dev] help with Infinispan OSGi
>> 
>> Brett, correct me if I?m wrong, but isn?t there a difference in making some library *work* in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled application? For example, making the JAR?s be OSGi bundles is easy and technically makes it possible to deploy a JAR into an OSGi env, but that?s not where the payoff is. IIUC what you really want is a BundleActivator or Declarative Services [1] so that the library?s components are readily available in a naturally-OSGi way.
>> 
>> [1] http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html
>> 
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>>> + infinispan-dev
>>> 
>>> Thanks for offering to look into this Brett!
>>> We're already producing OSGi bundles for our modules, but these are not tested extensively so if you'd review them and test them a bit would be great!
>>> Tristan can get you up to speed with this.
>>> 
>>> 
>>>>> Sanne/Galder/Pete,
>>>>> 
>>>>> Random question: what's the current state of making Infinispan OSGi friendly?  I'm definitely interested in helping, if it's still a need.  This past year, I went through the exercise of making Hibernate work well in OSGi, so all of challenges (read: *many* of them) are still fairly fresh on my mind.  Plus, I'd love for hibernate-infinispan to work in OSGi.
>>>>> 
>>>>> If you're up for it, fill me in?  I'm happy to pull everything down and start working with it.
>>>>> 
>>>>> Brett Meyer
>>>>> Software Engineer
>>>>> Red Hat, Hibernate ORM
>>>>> 
>>>> 
>>> 
>>> 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
>> 
>> 
>> _______________________________________________
>> 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



From galder at redhat.com  Thu Dec 19 02:52:03 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Thu, 19 Dec 2013 08:52:03 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <52AB28E7.3080706@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<7CBE1B77-8F45-490E-83B8-14DFD1F515EC@redhat.com>
	<52A1EA82.3000500@redhat.com>
	<5135A77E-971C-4147-ABBD-E399C636A4F0@redhat.com>
	<52AB28E7.3080706@redhat.com>
Message-ID: <083B74B9-A3DE-48EB-9625-5147A319A910@redhat.com>


On Dec 13, 2013, at 4:33 PM, Radim Vansa <rvansa at redhat.com> wrote:

> On 12/13/2013 03:49 PM, Galder Zamarre?o wrote:
>> On Dec 6, 2013, at 4:17 PM, Radim Vansa <rvansa at 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 about its own change?
>> If the call lands in a non-owner, it's probably simpler for the non-owner to send the notification there and then. ACK information tracking would probably be distributed, in which case it'd need to deal with potential failure of the primary owner.
> 
> I don't think I understand that properly. The node responsible for notifying the client is either primary owner, or operation origin (where the write has landed in fact). Previously, we were saying that the responsible node should be the primary owner - now you say that the origin. When the cluster is accessed only remotely, it does not have much performance impact (as these two are mostly the same node), but with cluster in compatibility mode the decision could affect the performance a lot.

Normally, a Hot Rod call would land on the owner of the key, which then is able to send the notification itself. The question, as you've rightly asked, is what to do when the call lands in a non-owner. Is that because the owner node has failed? Is it because the client has a flaky issue with the hash function and not all calls are directed to non-owners? Rather than spending time forcing the owner to be the one that sends the notification, a non-owner might say: something weird happened here, I should have received this call, but just in case, I'll send notifications linked to it.

> So, do you think that this should be the origin (easier to implement, with access to distributed ack registry it can retrieve the information, but with higher latency as the ack info is probably affine to the entry itself)
> or primary owner (in this case you'd have to propagate the source ID with the write command).
> Btw., what should be the source ID for operations coming from library mode? JGroups address of the node?

Personally, I think remote eventing is complex enough as it is to add compatibility in this first release because there's no event infrastructure for memcached nor REST. We should focus on getting remote events right for Hot Rod.

> 
> Radim
> 
>> 
>> Cheers,
>> --
>> Galder Zamarre?o
>> galder at redhat.com
>> twitter.com/galderz
>> 
>> Project Lead, Escalante
>> http://escalante.io
>> 
>> Engineer, Infinispan
>> http://infinispan.org
>> 
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
> 


--
Galder Zamarre?o
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org



From galder at redhat.com  Thu Dec 19 03:46:35 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Thu, 19 Dec 2013 09:46:35 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <20131213160805.GA12937@hibernate.org>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<20131213160805.GA12937@hibernate.org>
Message-ID: <283BDFDA-5F5F-43D8-897A-255010C34E74@redhat.com>


On Dec 13, 2013, at 5:08 PM, Emmanuel Bernard <emmanuel at 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 methods from RemoteFilter / RemoveConverter
> might be better.

I think the two are fairly tight in, so I think that might be a good idea.

> Should filter / converter impls have a @FilterId() / @ConverterId or
> should even the id be configured as late binding?

That falls into the configuration part which I hoped @Tristan would provide some insight on how we'd plug these filter/convert impls into the server. If they're defined via Infinispan configuration, the ID could be provided via there. If they're found via service loader pattern, annotations could be used, or callback methods. The former is probably more elegant.

> == Custom event contents
> 
> I an not following, is the custom content always received as byte[] by
> the client?  Or is the generic parameter K in
> RemoteCacheEntryCustomEvent<K> the actual return type of getEventData() ?
> 
> I'd love (in Java) to declare the returned type of the converter via
> generics in the RemoteConverter impl (class SomeRC<String> extends
> RemoteConverter<String> {}) and somehow use that information on
> the client side.

Event data is a byte[] as formatted by the converter on the server side. On the client side, I can only expose this as is, as byte[]. The callback would then need to disect it somehow.

The K in RemoteCacheEntryCustomEvent<K> should be removed really, since with these custom event calls, there's no key provided.

> == 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 query I want to run. Not only that but I'd love to be able to
> add a continuous query on the fly and disable it on the fly as well per
> client. For that filters and converters are not flexible enough.
> 
> What is missing is the ability to pass parameters from the client to
> the remote filter and remote converter. Parameters should be provided
> *per client*. Say Client 1 register the continuous query listener with
> "where age > 19" and client 2 registers the CQ listener with "where name
> = emmanuel". The filter knowing for which client it filters, it will be able to only
> return the keys that match the query.

This all sounds a bit like remote code exectution to me? You're asking for the client to pass some kind of executable thing that acts as a filter. That's a separate feature IMO, which I believe @Tristan is looking into. Once that's in place, I'm happy to enhance stuff in the remote event side to support it.

>From a remote event support perspective, server side static filter/converters is as far as I'd like to take it.

> Another useful but not fundamental notion is the ability for a client to
> enlist the same filter id / converter id tuple with different
> parameters. The same client might be interested in several different
> queries.
> 
> BTW have you considered some kind of multiplexing mechanism in case the
> several client listeners on the same client are interested in the same
> event?

If they're in the same client, they'd have the same source ID, so just sending it once would be doable, assuming they're not using different converters.

Cheers,

> 
> Emmanuel
> 
> On Thu 2013-12-05 17:16, Galder Zamarre?o wrote:
>> 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 have another read and let the list know what you think of it?
>> 
>> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
>> 
>> 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
> _______________________________________________
> 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



From emmanuel at hibernate.org  Thu Dec 19 07:15:36 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 19 Dec 2013 13:15:36 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <283BDFDA-5F5F-43D8-897A-255010C34E74@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<20131213160805.GA12937@hibernate.org>
	<283BDFDA-5F5F-43D8-897A-255010C34E74@redhat.com>
Message-ID: <20131219121536.GA12590@hibernate.org>

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 query I want to run. Not only that but I'd love to be able to
> > add a continuous query on the fly and disable it on the fly as well per
> > client. For that filters and converters are not flexible enough.
> > 
> > What is missing is the ability to pass parameters from the client to
> > the remote filter and remote converter. Parameters should be provided
> > *per client*. Say Client 1 register the continuous query listener with
> > "where age > 19" and client 2 registers the CQ listener with "where name
> > = emmanuel". The filter knowing for which client it filters, it will be able to only
> > return the keys that match the query.
> 
> This all sounds a bit like remote code exectution to me? You're asking for the client to pass some kind of executable thing that acts as a filter. That's a separate feature IMO, which I believe @Tristan is looking into. Once that's in place, I'm happy to enhance stuff in the remote event side to support it.

I don't think you are correct.
This is not remote execution in the sense of arbitrary code driven by
the client. Remote execution will likely be triggered, render a
result and stop. It will not send matching events in a continuous fashion.
Plus remote execution will likely involve dynamic languages and I'm not
sure we want to go that route for things like continuous query.

From ttarrant at redhat.com  Thu Dec 19 08:40:20 2013
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 19 Dec 2013 14:40:20 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
Message-ID: <52B2F744.1030202@redhat.com>

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 generating a unique 
session identifier at the end of a successful auth handshake. Such an 
identifier is then sent back from the client for all subsequent requests 
to avoid re-authentication. My plan was to tie this session id merely to 
the user's principal but this would not allow recognizing a 
dropped/restarted client.

My proposal is therefore that the HotRod protocol should add just one 
element which can serve both purposes.

Tristan

[1] https://github.com/infinispan/infinispan/wiki/Security

On 12/05/2013 05:16 PM, Galder Zamarre?o wrote:
> 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 have another read and let the list know what you think of it?
>
> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
>
> 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
>
>


From dan.berindei at gmail.com  Thu Dec 19 12:57:41 2013
From: dan.berindei at gmail.com (Dan Berindei)
Date: Thu, 19 Dec 2013 19:57:41 +0200
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <20131219121536.GA12590@hibernate.org>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<20131213160805.GA12937@hibernate.org>
	<283BDFDA-5F5F-43D8-897A-255010C34E74@redhat.com>
	<20131219121536.GA12590@hibernate.org>
Message-ID: <CA+nfvwQTFk0YJceNPucoJTFtLBkmkSiNQXM-b8scMXgyD5+EWA@mail.gmail.com>

On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard <emmanuel at 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 primary problem is that I don't want to enlist a filter id per
> > > continuous query I want to run. Not only that but I'd love to be able
> to
> > > add a continuous query on the fly and disable it on the fly as well per
> > > client. For that filters and converters are not flexible enough.
> > >
> > > What is missing is the ability to pass parameters from the client to
> > > the remote filter and remote converter. Parameters should be provided
> > > *per client*. Say Client 1 register the continuous query listener with
> > > "where age > 19" and client 2 registers the CQ listener with "where
> name
> > > = emmanuel". The filter knowing for which client it filters, it will
> be able to only
> > > return the keys that match the query.
> >
> > This all sounds a bit like remote code exectution to me? You're asking
> for the client to pass some kind of executable thing that acts as a filter.
> That's a separate feature IMO, which I believe @Tristan is looking into.
> Once that's in place, I'm happy to enhance stuff in the remote event side
> to support it.
>
> I don't think you are correct.
> This is not remote execution in the sense of arbitrary code driven by
> the client. Remote execution will likely be triggered, render a
> result and stop. It will not send matching events in a continuous fashion.
> Plus remote execution will likely involve dynamic languages and I'm not
> sure we want to go that route for things like continuous query.
>

To be clear, this is exactly the same as the filter parameters that Radim
was asking for, right? From Infinispan's point of view, the filter just
takes a String parameter, and the fact that that string can be parsed by
the filter in a particular language is irrelevant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131219/581cc584/attachment.html 

From emmanuel at hibernate.org  Thu Dec 19 13:43:41 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 19 Dec 2013 19:43:41 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <CA+nfvwQTFk0YJceNPucoJTFtLBkmkSiNQXM-b8scMXgyD5+EWA@mail.gmail.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<20131213160805.GA12937@hibernate.org>
	<283BDFDA-5F5F-43D8-897A-255010C34E74@redhat.com>
	<20131219121536.GA12590@hibernate.org>
	<CA+nfvwQTFk0YJceNPucoJTFtLBkmkSiNQXM-b8scMXgyD5+EWA@mail.gmail.com>
Message-ID: <20131219184341.GA3401@hibernate.org>

On Thu 2013-12-19 19:57, Dan Berindei wrote:
> On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard <emmanuel at 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 primary problem is that I don't want to enlist a filter id per
> > > > continuous query I want to run. Not only that but I'd love to be able
> > to
> > > > add a continuous query on the fly and disable it on the fly as well per
> > > > client. For that filters and converters are not flexible enough.
> > > >
> > > > What is missing is the ability to pass parameters from the client to
> > > > the remote filter and remote converter. Parameters should be provided
> > > > *per client*. Say Client 1 register the continuous query listener with
> > > > "where age > 19" and client 2 registers the CQ listener with "where
> > name
> > > > = emmanuel". The filter knowing for which client it filters, it will
> > be able to only
> > > > return the keys that match the query.
> > >
> > > This all sounds a bit like remote code exectution to me? You're asking
> > for the client to pass some kind of executable thing that acts as a filter.
> > That's a separate feature IMO, which I believe @Tristan is looking into.
> > Once that's in place, I'm happy to enhance stuff in the remote event side
> > to support it.
> >
> > I don't think you are correct.
> > This is not remote execution in the sense of arbitrary code driven by
> > the client. Remote execution will likely be triggered, render a
> > result and stop. It will not send matching events in a continuous fashion.
> > Plus remote execution will likely involve dynamic languages and I'm not
> > sure we want to go that route for things like continuous query.
> >
> 
> To be clear, this is exactly the same as the filter parameters that Radim
> was asking for, right? From Infinispan's point of view, the filter just
> takes a String parameter, and the fact that that string can be parsed by
> the filter in a particular language is irrelevant.

Not sure what string you are talking about. The filterid?

From dan.berindei at gmail.com  Fri Dec 20 05:09:42 2013
From: dan.berindei at gmail.com (Dan Berindei)
Date: Fri, 20 Dec 2013 12:09:42 +0200
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <20131219184341.GA3401@hibernate.org>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<20131213160805.GA12937@hibernate.org>
	<283BDFDA-5F5F-43D8-897A-255010C34E74@redhat.com>
	<20131219121536.GA12590@hibernate.org>
	<CA+nfvwQTFk0YJceNPucoJTFtLBkmkSiNQXM-b8scMXgyD5+EWA@mail.gmail.com>
	<20131219184341.GA3401@hibernate.org>
Message-ID: <CA+nfvwQgmq8JCZjpfguhw43Ox9wxybnMBCqrYXa8k4_fey4dYw@mail.gmail.com>

On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

> On Thu 2013-12-19 19:57, Dan Berindei wrote:
> > On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard <
> emmanuel at 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 primary problem is that I don't want to enlist a filter id per
> > > > > continuous query I want to run. Not only that but I'd love to be
> able
> > > to
> > > > > add a continuous query on the fly and disable it on the fly as
> well per
> > > > > client. For that filters and converters are not flexible enough.
> > > > >
> > > > > What is missing is the ability to pass parameters from the client
> to
> > > > > the remote filter and remote converter. Parameters should be
> provided
> > > > > *per client*. Say Client 1 register the continuous query listener
> with
> > > > > "where age > 19" and client 2 registers the CQ listener with "where
> > > name
> > > > > = emmanuel". The filter knowing for which client it filters, it
> will
> > > be able to only
> > > > > return the keys that match the query.
> > > >
> > > > This all sounds a bit like remote code exectution to me? You're
> asking
> > > for the client to pass some kind of executable thing that acts as a
> filter.
> > > That's a separate feature IMO, which I believe @Tristan is looking
> into.
> > > Once that's in place, I'm happy to enhance stuff in the remote event
> side
> > > to support it.
> > >
> > > I don't think you are correct.
> > > This is not remote execution in the sense of arbitrary code driven by
> > > the client. Remote execution will likely be triggered, render a
> > > result and stop. It will not send matching events in a continuous
> fashion.
> > > Plus remote execution will likely involve dynamic languages and I'm not
> > > sure we want to go that route for things like continuous query.
> > >
> >
> > To be clear, this is exactly the same as the filter parameters that Radim
> > was asking for, right? From Infinispan's point of view, the filter just
> > takes a String parameter, and the fact that that string can be parsed by
> > the filter in a particular language is irrelevant.
>
> Not sure what string you are talking about. The filterid?
>
>
I was referring to the condition string: "where age > 19", or "where name
= emmanuel".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131220/5cfe1662/attachment.html 

From dan.berindei at gmail.com  Fri Dec 20 05:13:41 2013
From: dan.berindei at gmail.com (Dan Berindei)
Date: Fri, 20 Dec 2013 12:13:41 +0200
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <52AB1585.7030602@redhat.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<52A19CC3.40807@redhat.com>
	<C5767B2C-3507-470A-A0FE-19A2D6A102A6@redhat.com>
	<52AB1585.7030602@redhat.com>
Message-ID: <CA+nfvwRtFaL-8S3MweCvac0RcBgaOy6-T2Zbw_YwA3+dWxmmzA@mail.gmail.com>

On Fri, Dec 13, 2013 at 4:11 PM, Radim Vansa <rvansa at redhat.com> wrote:

> On 12/13/2013 02:44 PM, Galder Zamarre?o wrote:
> > On Dec 6, 2013, at 10:45 AM, Radim Vansa <rvansa at 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
> filtering.
> > What do you mean by runtime parameter exactly? Can you give a concrete
> example of what you want to achieve that is not possible with what I've
> written up?
>
> As I stressed, if the client wants to listen for events on key_123456,
> then you can deploy a filter matching key_{number} (and additional
> constraints) but the 123456 is not known at deployment time.
>
> >
> >> 2) setting ack/no ack in listener, and then configuring server-wise
> whether you should ack each / only last event sounds weird. I'd replace the
> boolean with enum { NO_ACK, ACK_EACH, ACK_LAST }.
> > Makes a lot of sense, +1.
> >
> >> 3) should the client provide source id when registering listener or
> when starting RemoteCacheManager? No API for that.
> > Every operation will require a source ID from now on, so clients must
> provide it from first operation sent to the server. From a Java client
> perspective, you'd have this from the start via the configuration.
> >
> >> 4) clustered events design does not specify any means to replicating
> the clustered event listener - all it does is that you register the
> listener on one node and the other nodes then route events to this node,
> until the node dies/deregisters the listener. No replication. Please
> specify, how should it piggyback on clustered events, and how should the
> listener list be replicated.
> > In clustered listeners, the other nodes you talk about are gonna need to
> know about the clustered listeners so that they route events. Some kind of
> information about these clustered listeners will need to be sent around the
> cluster. The exact details are probably implementation details but we have
> a clustered registry already in place for this kind of things. In any case,
> it'd make a lot of sense that both use cases reuse as much as logic in this
> area.
>
> OK, this is probably the desired behaviour, it just is not covered by
> the Clustered Events design draft. Probably something to add - I'll ping
> Mircea about that. And you're right that it would make a lot of sense to
> have shared structure for the listeners, and two implementations of the
> delivery boy (one to the node where a clustered event has been
> registered and second to local component handling HotRod clients).
>
> >
> >> 5) non-acked events: how exactly do you expect the ack data to be
> replicated, and updated? I see three options:
> >> A) Let non-acked list be a part of the listener record in replicated
> cache, and the primary owner which executes the event should update these
> via delta messages. I guess for proper reliability it should add operation
> record synchronously before confirming the operation to the originator, and
> then it might asynchronously remove it after the ack from client. When a
> node becomes primary owner, it should send events to client for all
> non-acked events.
> >> B) Having the non-acked list attached directly to cache entry (updating
> it together with regular backup), and then asynchronously updating the
> non-ack list after ack comes
> >> C) Separate cache for acks by entry keys, similar to B, consistent hash
> synced with the main entry cache
> > Definitely not B. I don't wanna tie the internal cache entry to the
> ACKs. The two should be independent. Either C or A. For C, you'd wished to
> have a single cache for all listeners+caches, but you'd have to think about
> the keys and to have the same consistent hash, you'd have to have same
> keys. A might be better, but you certainly don't want this ACK info in a
> replicated structure. You'd want ACKs in a distributed cache preferably,
> and clustered listener info in the clustered replicated registry.
> There already is some CH implementation which aims at sharing the same
> distribution for all caches, SyncConsistentHash. Is there some problem
> with C and forcing this for the caches? Dan?
>
>
I'm not sure what the exact requirements would be here.

SyncConsistentHashFactory does ensure that the same key is mapped to the
same owners in all the caches using it, most of the time. However, it
requires both caches to have the same members, and since topologies aren't
applied at exactly the same time there will be periods when the owners in
the two caches won't match.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131220/cfff5c4b/attachment.html 

From emmanuel at hibernate.org  Fri Dec 20 05:20:40 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 20 Dec 2013 11:20:40 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <CA+nfvwQgmq8JCZjpfguhw43Ox9wxybnMBCqrYXa8k4_fey4dYw@mail.gmail.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<20131213160805.GA12937@hibernate.org>
	<283BDFDA-5F5F-43D8-897A-255010C34E74@redhat.com>
	<20131219121536.GA12590@hibernate.org>
	<CA+nfvwQTFk0YJceNPucoJTFtLBkmkSiNQXM-b8scMXgyD5+EWA@mail.gmail.com>
	<20131219184341.GA3401@hibernate.org>
	<CA+nfvwQgmq8JCZjpfguhw43Ox9wxybnMBCqrYXa8k4_fey4dYw@mail.gmail.com>
Message-ID: <20131220102040.GA1014@hibernate.org>

On Fri 2013-12-20 12:09, Dan Berindei wrote:
> On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
> 
> > On Thu 2013-12-19 19:57, Dan Berindei wrote:
> > > On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard <
> > emmanuel at 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 primary problem is that I don't want to enlist a filter id per
> > > > > > continuous query I want to run. Not only that but I'd love to be
> > able
> > > > to
> > > > > > add a continuous query on the fly and disable it on the fly as
> > well per
> > > > > > client. For that filters and converters are not flexible enough.
> > > > > >
> > > > > > What is missing is the ability to pass parameters from the client
> > to
> > > > > > the remote filter and remote converter. Parameters should be
> > provided
> > > > > > *per client*. Say Client 1 register the continuous query listener
> > with
> > > > > > "where age > 19" and client 2 registers the CQ listener with "where
> > > > name
> > > > > > = emmanuel". The filter knowing for which client it filters, it
> > will
> > > > be able to only
> > > > > > return the keys that match the query.
> > > > >
> > > > > This all sounds a bit like remote code exectution to me? You're
> > asking
> > > > for the client to pass some kind of executable thing that acts as a
> > filter.
> > > > That's a separate feature IMO, which I believe @Tristan is looking
> > into.
> > > > Once that's in place, I'm happy to enhance stuff in the remote event
> > side
> > > > to support it.
> > > >
> > > > I don't think you are correct.
> > > > This is not remote execution in the sense of arbitrary code driven by
> > > > the client. Remote execution will likely be triggered, render a
> > > > result and stop. It will not send matching events in a continuous
> > fashion.
> > > > Plus remote execution will likely involve dynamic languages and I'm not
> > > > sure we want to go that route for things like continuous query.
> > > >
> > >
> > > To be clear, this is exactly the same as the filter parameters that Radim
> > > was asking for, right? From Infinispan's point of view, the filter just
> > > takes a String parameter, and the fact that that string can be parsed by
> > > the filter in a particular language is irrelevant.
> >
> > Not sure what string you are talking about. The filterid?
> >
> >
> I was referring to the condition string: "where age > 19", or "where name
> = emmanuel".

OK. I am not sure that the fact that the parameter is a string in both
cases and that there is only one parameter and not multiple is particularly relevant
to the general problem at hand.

From dan.berindei at gmail.com  Fri Dec 20 06:08:12 2013
From: dan.berindei at gmail.com (Dan Berindei)
Date: Fri, 20 Dec 2013 13:08:12 +0200
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <20131220102040.GA1014@hibernate.org>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<20131213160805.GA12937@hibernate.org>
	<283BDFDA-5F5F-43D8-897A-255010C34E74@redhat.com>
	<20131219121536.GA12590@hibernate.org>
	<CA+nfvwQTFk0YJceNPucoJTFtLBkmkSiNQXM-b8scMXgyD5+EWA@mail.gmail.com>
	<20131219184341.GA3401@hibernate.org>
	<CA+nfvwQgmq8JCZjpfguhw43Ox9wxybnMBCqrYXa8k4_fey4dYw@mail.gmail.com>
	<20131220102040.GA1014@hibernate.org>
Message-ID: <CA+nfvwT3k0ctOaFPU6H5FTcCtknf1a=St9ALn83LGvoyyJb36Q@mail.gmail.com>

On Fri, Dec 20, 2013 at 12:20 PM, Emmanuel Bernard
<emmanuel at hibernate.org>wrote:

> On Fri 2013-12-20 12:09, Dan Berindei wrote:
> > On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard <
> emmanuel at hibernate.org>wrote:
> >
> > > On Thu 2013-12-19 19:57, Dan Berindei wrote:
> > > > On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard <
> > > emmanuel at 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 primary problem is that I don't want to enlist a filter id
> per
> > > > > > > continuous query I want to run. Not only that but I'd love to
> be
> > > able
> > > > > to
> > > > > > > add a continuous query on the fly and disable it on the fly as
> > > well per
> > > > > > > client. For that filters and converters are not flexible
> enough.
> > > > > > >
> > > > > > > What is missing is the ability to pass parameters from the
> client
> > > to
> > > > > > > the remote filter and remote converter. Parameters should be
> > > provided
> > > > > > > *per client*. Say Client 1 register the continuous query
> listener
> > > with
> > > > > > > "where age > 19" and client 2 registers the CQ listener with
> "where
> > > > > name
> > > > > > > = emmanuel". The filter knowing for which client it filters, it
> > > will
> > > > > be able to only
> > > > > > > return the keys that match the query.
> > > > > >
> > > > > > This all sounds a bit like remote code exectution to me? You're
> > > asking
> > > > > for the client to pass some kind of executable thing that acts as a
> > > filter.
> > > > > That's a separate feature IMO, which I believe @Tristan is looking
> > > into.
> > > > > Once that's in place, I'm happy to enhance stuff in the remote
> event
> > > side
> > > > > to support it.
> > > > >
> > > > > I don't think you are correct.
> > > > > This is not remote execution in the sense of arbitrary code driven
> by
> > > > > the client. Remote execution will likely be triggered, render a
> > > > > result and stop. It will not send matching events in a continuous
> > > fashion.
> > > > > Plus remote execution will likely involve dynamic languages and
> I'm not
> > > > > sure we want to go that route for things like continuous query.
> > > > >
> > > >
> > > > To be clear, this is exactly the same as the filter parameters that
> Radim
> > > > was asking for, right? From Infinispan's point of view, the filter
> just
> > > > takes a String parameter, and the fact that that string can be
> parsed by
> > > > the filter in a particular language is irrelevant.
> > >
> > > Not sure what string you are talking about. The filterid?
> > >
> > >
> > I was referring to the condition string: "where age > 19", or "where name
> > = emmanuel".
>
> OK. I am not sure that the fact that the parameter is a string in both
> cases and that there is only one parameter and not multiple is
> particularly relevant
> to the general problem at hand.
>
>
I don't think so either, I was just asking if you think there is any
difference between what you're asking for and what Radim was asking for...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131220/d3c6c772/attachment-0001.html 

From anistor at redhat.com  Fri Dec 20 07:41:55 2013
From: anistor at redhat.com (Adrian Nistor)
Date: Fri, 20 Dec 2013 14:41:55 +0200
Subject: [infinispan-dev] Hot rod version 1.3 and QueryOperation
In-Reply-To: <52A70D36.8070901@redhat.com>
References: <52A70D36.8070901@redhat.com>
Message-ID: <52B43B13.9070608@redhat.com>

Hi Michal,

This is now fixed in master, see 
https://issues.jboss.org/browse/ISPN-3812 and 
https://issues.jboss.org/browse/ISPN-3688

Java client is now using version 1.3 as expected, but the validation you 
suggested for server (support query only for 13 and not 12) was not 
added. This is in line with previous approach to such validations. 
Server complains if either of the client version or operation code is 
not recognized but does not validate that the tuple makes sense as per 
protocol spec.

Cheers

On 12/10/2013 02:46 PM, Michal Linhard wrote:
> Hi,
>
> I'm checking the JDG 6.2.0 Docs on Hot Rod protocol that should describe
> the 1.3 version
>
> I realized that we don't actually fill version number 13 yet, i.e.
> there's no such thing as HotRodConstants.VERSION_13 yet
> but we already added HotRodConstants.QUERY_REQUEST = 0x1F; to protocol
> 1.2 which is in contradiction with docs
> that says queries come in version 1.3:
> http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_hot_rod_protocol
>
> how do we plan to solve this ?
> is this a bug and are we going to create version 13, whereby query op
> will be supported only there and not in 12 ?
>
> m.
>


From emmanuel at hibernate.org  Fri Dec 20 09:30:28 2013
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 20 Dec 2013 15:30:28 +0100
Subject: [infinispan-dev] Design of Remote Hot Rod events - round 2
In-Reply-To: <CA+nfvwT3k0ctOaFPU6H5FTcCtknf1a=St9ALn83LGvoyyJb36Q@mail.gmail.com>
References: <11A2709F-3194-439C-8D8B-95D2FF38213C@redhat.com>
	<20131213160805.GA12937@hibernate.org>
	<283BDFDA-5F5F-43D8-897A-255010C34E74@redhat.com>
	<20131219121536.GA12590@hibernate.org>
	<CA+nfvwQTFk0YJceNPucoJTFtLBkmkSiNQXM-b8scMXgyD5+EWA@mail.gmail.com>
	<20131219184341.GA3401@hibernate.org>
	<CA+nfvwQgmq8JCZjpfguhw43Ox9wxybnMBCqrYXa8k4_fey4dYw@mail.gmail.com>
	<20131220102040.GA1014@hibernate.org>
	<CA+nfvwT3k0ctOaFPU6H5FTcCtknf1a=St9ALn83LGvoyyJb36Q@mail.gmail.com>
Message-ID: <20131220143028.GA9683@hibernate.org>

On Fri 2013-12-20 13:08, Dan Berindei wrote:
> On Fri, Dec 20, 2013 at 12:20 PM, Emmanuel Bernard
> > OK. I am not sure that the fact that the parameter is a string in both
> > cases and that there is only one parameter and not multiple is
> > particularly relevant
> > to the general problem at hand.
> >
> >
> I don't think so either, I was just asking if you think there is any
> difference between what you're asking for and what Radim was asking for...

To be honest I wrote my email before reading the rest of the thread and
did not pay much attention to Radim's email :) So I'd say maybe ;)
At any rate that's for a different use case, so it gives an additional
data point.

From galder at redhat.com  Tue Dec 24 03:38:36 2013
From: galder at redhat.com (=?iso-8859-1?Q?Galder_Zamarre=F1o?=)
Date: Tue, 24 Dec 2013 09:38:36 +0100
Subject: [infinispan-dev] help with Infinispan OSGi
In-Reply-To: <CAJ6eY0Z3tc5Ta6iWjvRiEnuyz8DjHQG3SndhcS3p3PnSqnx_LA@mail.gmail.com>
References: <CAJ6eY0Z3tc5Ta6iWjvRiEnuyz8DjHQG3SndhcS3p3PnSqnx_LA@mail.gmail.com>
Message-ID: <56A052AE-1E29-428C-9C38-69A5EFBFC07E@redhat.com>

Thanks a lot Bilgin. 

One of our colleagues has also been looking into Infinispan's integration into OSGI containers, see [1] dev list thread.

Cheers,

[1] http://lists.jboss.org/pipermail/infinispan-dev/2013-December/014272.html

On Dec 17, 2013, at 11:49 PM, Bilgin Ibryam <bibryam at gmail.com> wrote:

> 
> Hi guys,
> 
> some time ago I created camel-infinispan component [1] and when I tried to deploy that on an OSGI container, all the fun began :)
> 
> You can see all the steps [2] I had to do in order to deploy Infinispan jars on OSGI. They are far from the optimal but should give you some pointers to things to fix while working on it. 
> 
> Looking forward seeing on Infinispan on OSGI, right now it is a showstopper for couple of POCs.
> 
> 
> [1] http://camel.apache.org/infinispan.html
> [2] https://github.com/bibryam/camel-infinispan-osgi
> 
> Cheers,
> 
> -- 
> Bilgin Ibryam
> 
> Apache Camel & Apache OFBiz committer
> Blog: ofbizian.com
> Twitter: @bibryam
> 
> Author of Instant Apache Camel Message Routing 
> http://www.amazon.com/dp/1783283475
> _______________________________________________
> 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



From guillaume.scheibel at gmail.com  Thu Dec 26 16:32:27 2013
From: guillaume.scheibel at gmail.com (Guillaume SCHEIBEL)
Date: Thu, 26 Dec 2013 22:32:27 +0100
Subject: [infinispan-dev] Synchronous write on cachestore
Message-ID: <CAJoPwXd8Md7JAYW=ETmn2h=mEE8OAwsoZMncxNhTudYzxCOy5Q@mail.gmail.com>

Hello everyone,

I'm fixing some issues on the MongoDB cachestore configuration (v5.3). I've
written a test [1] to check that the value I've added in the cache is
correctly persisted into my MongoDB collection.

The problem is that when comes at the "assert" time, the value put in the
cache has still not been stored in MongoDB.

So how can I do to have the value directly persisted into the cache store
database ?

Thanks
Guillaume

[1] https://gist.github.com/gscheibel/8138722
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131226/b1b506d3/attachment.html