Re: [infinispan-dev] Fwd: ISPN-2808 - thread pool for incoming message [feedback]

2013-02-28 Thread Bela Ban
On 2/27/13 8:10 PM, Pedro Ruivo wrote: Original Message Subject: ISPN-2808 - thread pool for incoming message [feedback] Date: Wed, 27 Feb 2013 19:06:49 + From: Pedro Ruivo pe...@infinispan.org To: infinispan-core-...@infinispan.org infinispan-core-...@infinispan.org

[infinispan-dev] JGroups 3.3.0.Beta1

2013-02-28 Thread Bela Ban
FYI, added to Nexus. This completes the implementation of message batching in all protocols, and contains the complete Async Invocation API as well. Once we have an implementation of async request handling in Infinispan, which runs independent transactions in separate threads from an internal

Re: [infinispan-dev] JGroups 3.3.0.Beta1

2013-02-28 Thread Sanne Grinovero
Very nice, thanks Bela! I'm wondering if I should upgrade the next crop of Search technology to use it. In other words, do you expect the 3.3 line to be included in EAP 6.1 ? Otherwise I'm stuck on older version. Sanne On 28 February 2013 11:58, Bela Ban b...@redhat.com wrote: FYI, added to

Re: [infinispan-dev] ISPN-2808 - thread pool for incoming message [feedback]

2013-02-28 Thread Mircea Markus
On 27 Feb 2013, at 19:06, Pedro Ruivo wrote: Hi all, I'm working on ISPN-2808 and I want some feedback about it (code is here [1]) I'm starting to implement this feature but I know that Asynchronous Invocation API is not totally finished in JGroups. My idea in to use an executor

Re: [infinispan-dev] JGroups 3.3.0.Beta1

2013-02-28 Thread Bela Ban
Thx, I'm afraid I don't know which components are going to be included in EAP 6.1; ask the EAP folks. On 2/28/13 1:14 PM, Sanne Grinovero wrote: Very nice, thanks Bela! I'm wondering if I should upgrade the next crop of Search technology to use it. In other words, do you expect the 3.3 line

Re: [infinispan-dev] ISPN-2808 - thread pool for incoming message [feedback]

2013-02-28 Thread Pedro Ruivo
On 02/28/2013 12:18 PM, Mircea Markus wrote: On 27 Feb 2013, at 19:06, Pedro Ruivo wrote: Hi all, I'm working on ISPN-2808 and I want some feedback about it (code is here [1]) I'm starting to implement this feature but I know that Asynchronous Invocation API is not totally finished in

Re: [infinispan-dev] ISPN-2808 - thread pool for incoming message [feedback]

2013-02-28 Thread Mircea Markus
On 28 Feb 2013, at 15:31, Pedro Ruivo wrote: On 27 Feb 2013, at 19:06, Pedro Ruivo wrote: Hi all, I'm working on ISPN-2808 and I want some feedback about it (code is here [1]) I'm starting to implement this feature but I know that Asynchronous Invocation API is not totally finished

Re: [infinispan-dev] ISPN-2808 - thread pool for incoming message [feedback]

2013-02-28 Thread Dan Berindei
On Thu, Feb 28, 2013 at 2:18 PM, Mircea Markus mmar...@redhat.com wrote: On 27 Feb 2013, at 19:06, Pedro Ruivo wrote: Hi all, I'm working on ISPN-2808 and I want some feedback about it (code is here [1]) I'm starting to implement this feature but I know that Asynchronous Invocation API

Re: [infinispan-dev] ISPN-2808 - thread pool for incoming message [feedback]

2013-02-28 Thread Dan Berindei
Actually some of the commands you mentioned don't go through the interceptor chain (CacheTopologyControlCommand, StateRequestCommand, StateRequestCommand etc.) so you can't use an interceptor to move them to a separate thread pool. On Thu, Feb 28, 2013 at 5:47 PM, Mircea Markus

Re: [infinispan-dev] ISPN-2808 - thread pool for incoming message [feedback]

2013-02-28 Thread Pedro Ruivo
On 02/28/2013 03:47 PM, Mircea Markus wrote: On 28 Feb 2013, at 15:31, Pedro Ruivo wrote: On 27 Feb 2013, at 19:06, Pedro Ruivo wrote: Hi all, I'm working on ISPN-2808 and I want some feedback about it (code is here [1]) I'm starting to implement this feature but I know that

Re: [infinispan-dev] ISPN-2808 - thread pool for incoming message [feedback]

2013-02-28 Thread Mircea Markus
On 28 Feb 2013, at 17:30, Pedro Ruivo wrote: chain the better. So do you think that is better to create a new interceptor to dispatch the commands to the thread pool? (at least for the VisitableCommands). And put this new interceptor after the InvocationContextInterceptor? we shouldn't