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

[Ales Justin]

@Bela -- I can help you setup the whole CD env. ;-)

On Apr 15, 2013, at 7:14 AM, Bela Ban <bban at redhat.com> wrote:

> 
> 
> 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)
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev