[infinispan-dev] [hibernate-dev] HSEARCH-1296

[Bela Ban]

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