@Bela -- I can help you setup the whole CD env. ;-) On Apr 15, 2013, at 7:14 AM, Bela Ban <[email protected]> wrote:
> > > On 4/13/13 1:42 PM, Sanne Grinovero wrote: >> On 13 April 2013 11:20, Bela Ban <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
