Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Dan Berindei
On Wed, Jul 30, 2014 at 12:35 AM, Sanne Grinovero wrote: > On 29 July 2014 22:14, Dan Berindei wrote: > > > > On Tue, Jul 29, 2014 at 9:06 PM, Sanne Grinovero > > wrote: > >> > >> This is a nasty problem and I also feel passionately we need to get > >> rid of it ASAP. > >> I did have the same p

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Pedro Ruivo
On 07/29/2014 10:14 PM, Dan Berindei wrote: > > > > It's also conceptually linked to: > - https://issues.jboss.org/browse/ISPN-1599 > As you need to separate the locks of entries from the effective user > facing lock, at least to implement transactions on top of this model. > >

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Pedro Ruivo
On 07/30/2014 09:02 AM, Dan Berindei wrote: > > > if your proposal is only meant to apply to non-tx caches, you are right > you don't have to worry about multiple primary owners... most of the > time. But when the primary owner changes, then you do have 2 primary > owners (if the new primary own

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Dan Berindei
On Wed, Jul 30, 2014 at 12:00 PM, Pedro Ruivo wrote: > > > On 07/30/2014 09:02 AM, Dan Berindei wrote: > > > > > > > if your proposal is only meant to apply to non-tx caches, you are right > > you don't have to worry about multiple primary owners... most of the > > time. But when the primary owne

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Radim Vansa
Investigation: When I looked at UNICAST3, I saw a lot of missing messages on the receive side and unacked messages on the send side. This caused me to look into the (mainly OOB) thread pools and - voila - maxed out ! I learned from Pedro that the Infinispan

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Bela Ban
On 29/07/14 16:39, Dan Berindei wrote: > Investigation: > > This mitigated the problem somewhat, but when I increased the requester > threads to 100, I had the same problem again. Apparently, the Infinispan > internal thread pool uses a rejection policy of "run"

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Bela Ban
Quick update. Even when I changed the number of segments from 60 (default) to 1000 (on Dan's suggestion), I still got lock aquisition timeouts with regular TXs and in the TX-less case, too. With total order, I had not single issue in a couple of runs, one of them on 500 nodes with 200 reques

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Bela Ban
On 29/07/14 20:06, Sanne Grinovero wrote: > This is a nasty problem and I also feel passionately we need to get > rid of it ASAP. +1 > I did have the same problems many times, and we discussed this also in > Farnborough; AFAIR Dan and Pedro had some excellent ideas to fix this. > > You don't ne

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Bela Ban
On 29/07/14 23:14, Dan Berindei wrote: > > On Tue, Jul 29, 2014 at 9:06 PM, Sanne Grinovero > wrote: > > This is a nasty problem and I also feel passionately we need to get > rid of it ASAP. > I did have the same problems many times, and we discussed this

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Bela Ban
On 29/07/14 23:35, Sanne Grinovero wrote: > The strategy I've proposed is only to be applied for the communication > from the primary owner to its backups: > the value to be written is well known as it's the primary owner which > defines it unilaterally (for example if there is an atomic replace

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Dan Berindei
On Wed, Jul 30, 2014 at 12:22 PM, Radim Vansa wrote: > > Investigation: >> >> When I looked at UNICAST3, I saw a lot of missing messages on the >> receive side and unacked messages on the send side. This caused me to >> look into the (mainly OOB) thread pools and - voila - maxed ou

Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution

2014-07-30 Thread Radim Vansa
On 07/30/2014 01:59 PM, Dan Berindei wrote: On Wed, Jul 30, 2014 at 12:22 PM, Radim Vansa > wrote: Investigation: When I looked at UNICAST3, I saw a lot of missing messages on the receive side and unacked messages on th

Re: [infinispan-dev] On ParserRegistry and classloaders

2014-07-30 Thread Mircea Markus
Ion, Martin - what are your thoughts? On Jul 29, 2014, at 16:34, Sanne Grinovero wrote: > All, > in Search we wrap the Parser in a decorator which workarounds the > classloader limitation. > I still think you should fix this, it doesn't matter how/why it was changed. > > Sanne > > On 26 May 20

Re: [infinispan-dev] On ParserRegistry and classloaders

2014-07-30 Thread Ion Savin
Hi Sanne, I don't see any changes in the ParserRegistry which would have removed the behavior you describe (at least looking at the OSGi changes). Can you point me please to some code which used to work in the past? I've found two classes which have some reference to Hibernate in comments and