On 4/13/13 1:42 PM, Sanne Grinovero wrote: > On 13 April 2013 11:20, Bela Ban <b...@redhat.com> wrote: >> >> >> On 4/13/13 2:02 AM, Sanne Grinovero wrote: >> >>> @All, the performance problem seemed to be caused by a problem in >>> JGroups, which I've logged here: >>> https://issues.jboss.org/browse/JGRP-1617 >> >> >> Almost no information attached to the case :-( If it wasn't you, Sanne, >> I'd outright reject the case ... > > I wouldn't blame you, and am sorry for the lack of details: as I said > it was very late, still I preferred to share the observations we made > so far.
OK, but I'll need more info if you want me to look into this. >>From all the experiments we made - and some good logs I'll cleanup for > sharing - it's clear that the thread is not woken up while the ACK was > already received. How do you know the ack has been received ? Logs ? Debugging ? > And of course I wouldn't expect this to fail in a simple test as it > wouldn't have escaped you ;-) or at least you would have had earlier > reports. > > There are lots of complex moving parts in this scenario: from a Muxed > JGroups Channel, and the Application Server responsible for > initializing the stack with some added magic from CapeDwarf itself: > it's not clear to me what configuration is exactly being used, for one. I see. > Without a testcase we might not be 100% sure but it seems likely to be > an unexpected behaviour in JGroups, at least under some very specific > setup. > > I'm glad to help tracking down more details of what could trigger > this, but I'm not too eager to write a full unit test for this as it > involves a lot of other components, and by mocking my own components > out I could still reproduce it: it's not Hibernate Search, so I'll > need the help from the field experts. It would at least be nice to have some logs. I understand that even though the test involves many components, it is short lived, so logs (even at TRACE) shouldn't be too big. >> If you add more information to JGRP-1617, I'll take a look. This would >> be a critical bug in JGroups *if* you can prove that the >> MessageDispatcher always runs into the timeout (I don't think you can >> though !). > > Considering the easy workaround and that definitely this needs > something special in the configuration, I wouldn't consider it too > critical? For as far as we know now, it's entirely possible the > configuration being used is illegal. But this is exactly where I need > your help ;-) I'm here to help. But I need more information. -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
