Brilliant, that session counter assertion is already paying off.  I won’t
be able to look at it before next weekend.  Regular work-work during the
week and all.  Cheers!

On Mon, Feb 12, 2018 at 8:02 AM, Christoph John <christoph.j...@macd.com>
wrote:

> Hi Jonathan,
>
> thanks again for your work on DIRMINA-1076. I think I might have
> encountered a related case and openend DIRMINA-1077for it.
>
> Thanks in advance and best regards,
> Christoph.
>
>
>
> On 09/02/18 15:22, Christoph John wrote:
>
>> OK, no problem. Just created https://issues.apache.org/jira
>> /browse/DIRMINA-1076
>>
>> Thanks in advanceand best regards,
>> Chris.
>>
>>
>> On 09/02/18 15:11, Jonathan Valliere wrote:
>>
>>> If there isn’t a ticket in JIRA, please create one.  I’d prefer to work
>>> there instead of email.
>>>
>>>
>>> On Fri, Feb 9, 2018 at 8:56 AM Christoph John <christoph.j...@macd.com
>>> <mailto:christoph.j...@macd.com>> wrote:
>>>
>>>     Yes, that is the patch that I attached. It is simply executing the
>>> test in
>>>     AbstractIoServiceTest in
>>>     a loop.
>>>
>>>     Thanks,
>>>     Chris.
>>>
>>>     On 09/02/18 14:47, Jonathan Valliere wrote:
>>>     > It’s been a while, I forget, is there code to run the brute force
>>> test available?
>>>     >
>>>     > On Fri, Feb 9, 2018 at 7:56 AM Christoph John <
>>> christoph.j...@macd.com
>>>     <mailto:christoph.j...@macd.com>
>>>     > <mailto:christoph.j...@macd.com <mailto:christoph.j...@macd.com>>>
>>> wrote:
>>>     >
>>>     >     Hi againafter some time. ;)
>>>     >
>>>     >     I was now able to reproduce the problem with a MINA test. Or
>>> let's say I did the brute-force
>>>     >     approach by re-running one test in an endless loop.
>>>     >     I have attached apatch of the test (against
>>> https://github.com/apache/mina/tree/2.0
>>>     <https://github.com/apache/mina/tree/2.0>) and a
>>>     >     stack trace. After a few loops the test is stuck. You can see
>>> a lot of threads hanging in
>>>     >     dispose() and the test is stuck when it tries to dispose the
>>> acceptor.
>>>     >
>>>     >     What is a little strange is that the javadoc says that
>>> connector.dispose(TRUE) should not be
>>>     >     called from an IoFutureListener, but in the test it is done
>>> anyway. However, changing the
>>>     >     parameter to FALSE does not help either.
>>>     >
>>>     >     Is there anything that can be done to prevent this hang?
>>>     >
>>>     >     Many thanks in advance for your help and best regards,
>>>     >     Chris.
>>>     >
>>>     >
>>>
>>>
>>
> --
> Christoph John
> Development & Support
> T +49 241 557080-28
> christoph.j...@macd.com
>
> MACD GmbH
> Oppenhoffallee 103
> D-52066 Aachen
> www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Reply via email to