On 4/13/13 1:42 PM, Sanne Grinovero wrote:
On 13 April 2013 11:20, Bela Ban <bban(a)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)