Re: [Quickfixj-users] Multiple logons/connections for this session are not allowed

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi guys.

I am still facing this issue and now the frequency is very high. I am also
not able to detect any networking issue.

One more point is, it is happening with all clients at same time.  This
does not resolve without the restart of application.
One more strange thing is if I don't restart, then the client which was
disconnected at the time of this issue, when try to connect at their
session time also facing this issue.

So now I am highly suspecting this as quickfix bug.

As per me quickfixj should close old session if it detect that old session
is still running when it receive new logon. To achieve the same I am
thinking to edit *AcceptorIoHandler.java.*

Class :  AcceptorIoHandler.java
Line no 69
if (qfSession.hasResponder()) {
             // Session is already bound to another connection
             sessionLog.onErrorEvent("Multiple logons/connections for this
session are not allowed");
             protocolSession.closeNow();
             *//TODO Close old session here*
             return;
  }

There are many methods to close the session in Session class as following

   1.    qfSession.close();
   2.    qfSession.disconnect("Closing Old session", true);
   3.    qfSession.logout("Closing old session to accommodate new session");
   4.    qfSession.generateLogout();
   5.    qfSession.reset();

Which of the above method I should opt for, that can serve my purpose ?

Thanks
Vipin

On Mon, May 4, 2020 at 3:47 PM Christoph John <chr...@ma...>
wrote:

> Hi,
>
> if VPN rekeying is not the problem then maybe differing MTU sizes or
> asymmetric routing. Or of course it could also be another problem. Just
> said what the problems mostly were in our case.
> But I think if you describe the problem to your and your counterparty's
> network team (since you only seem to have this problem with some of your
> sessions) they should be able to debug it. Maybe your team need to do some
> tcp dumps around the time of the problem.
>
> It would be nice if you could reply to the user group (not me privately)
> if you found something out. This could help other users as well.
>
> Cheers,
> Chris.
>
>
> On 04.05.20 08:28, Vipin Chaudhary wrote:
>
> Hi Christoph,
>
> I double checked from the network team and find that no initiator use VPN
> to connect to us.
>
> In that case, Can you help me on what should I request to network team to
> fix the network connections?
>
> Thanks
> Vipin Chaudhary
>
> On Thu, Apr 30, 2020 at 3:49 PM Christoph John <chr...@ma...>
> wrote:
>
>> The only solution is to fix the network connection. Everything else is
>> only a workaround.
>> You could try to increase socket timeouts on both sides of the
>> connection. Maybe it helps (depends on the cause of the problem) but as
>> said this will only work around the problem.
>>
>> Cheers,
>> Chris.
>>
>> On 30.04.20 12:11, Vipin Chaudhary wrote:
>>
>> Hi Christoph,
>>
>> Thanks for your input,
>>
>> We have multiple sessions and this problems does not happens with all
>> sessions simultaneously. Mostly we see this problem with one session and
>> rarely with other session.
>>
>> As far as I know initiator connect directly with us over internet (have
>> ssl). Will double check on this with network team.
>>
>> Meanwhile any solution you think of this problem ?
>>
>> Thanks
>> Vipin Chaudhary
>>
>> On Thu, Apr 30, 2020 at 3:31 PM Christoph John <chr...@ma...>
>> wrote:
>>
>>> Addition: if VPN rekeying is the problem you will probably see this
>>> message every hour (or whatever the rekey interval is)
>>>
>>> Chris.
>>>
>>> On 30.04.20 12:00, Christoph John wrote:
>>>
>>> Hi,
>>>
>>> did you change QFJ version or why do you think it is QFJ related? Do you
>>> only have one FIX session? If not, do all sessions show this behaviour?
>>> (apart from that, the TCP/IP stuff is done via the MINA framework and
>>> not within QFJ itself)
>>>
>>> This message appears when the initiator side of the connection considers
>>> the connection broken and tries to reconnect. But the acceptor still
>>> considers it a vital connection (probably until the connection timeout
>>> kicks in).
>>>
>>> From my experience this happens mostly on VPN connections via internet.
>>> Reasons for this were one of:
>>>  - different MTU sizes on both sides of the connection or on a
>>> router/firewall in between
>>>  - asymmetric routing
>>>  - differing VPN parameters leading to different rekeying behaviour on
>>> both ends of the connection.
>>>
>>> Hope that helps,
>>> Chris.
>>>
>>>
>>> On 30.04.20 05:51, Vipin Chaudhary wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Hi Team,
>>>
>>> We are facing strange issue with quickfixj.
>>>
>>> We are SessionAcceptor, sometime when initiator disconnect, then
>>> quickfixj is not able to recognize the disconnection. So when client logon
>>> next time it say
>>> " Multiple logons/connections for this session are not allowed".
>>>   Although in reality client is disconnected.
>>> Earlier it was very rare and happening once in a while but nowadays its
>>> happening like once in week.
>>> Quickfixj is not able to recover from this and we need to restart our
>>> application
>>>
>>> *Do anyone have seen/fix this ?*
>>>
>>> Thanks
>>> Vipin Chaudhary
>>>
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>>
>>> --
>>> Christoph John
>>> Software Engineering
>>> T +49 241 557...@ma...
>>>
>>> MACD GmbH
>>> Oppenhoffallee 103
>>> 52066 Aachen, Germanywww.macd.com
>>>
>>> Amtsgericht Aachen: HRB 8151
>>> Ust.-Id: DE 813021663
>>> Geschäftsführer: George Macdonald
>>>
>>>
>>> --
>>> Christoph John
>>> Software Engineering
>>> T +49 241 557...@ma...
>>>
>>> MACD GmbH
>>> Oppenhoffallee 103
>>> 52066 Aachen, Germanywww.macd.com
>>>
>>> Amtsgericht Aachen: HRB 8151
>>> Ust.-Id: DE 813021663
>>> Geschäftsführer: George Macdonald
>>>
>>>
>> --
>> Christoph John
>> Software Engineering
>> T +49 241 557...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germanywww.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>