Quantcast

FIX acceptor

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FIX acceptor

Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I have an issue now with my dynamic FIX acceptor, if I disconnect a session from the server and enable it again, the client is able to reconnect, but if the initiator disconnects and try to connect again it constantly stays on the Logon, Disconnect cycle.

It seems like if the session encounters a END_OF_STREAM it cannot connect again.
How to properly clean a disconnected session from the acceptor? Help appreciate, I have been debugging for hours now and no luck.

Best regards,

Guido.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIX acceptor

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Guido,

hmm, actually the END_OF_STREAM message is queued when the session gets closed. So I assume that the
END_OF_STREAM is the result of the Session not getting established but disconnected at once.
Is this maybe related to your other question from a few weeks ago? The
DynamicAcceptorSessionProvider will return null when a Session is not found and hence the Session
will not get accepted. (attached)
Or do you have another mechanism in place to check if the session has to be accepted?

Is there something different about when the initiator connects for the first time vs. when it tries
to connect after a disconnection? There is nothing in the event logs about this?

Of course, it might as well be a bug.

Cheers,
Chris.



On 03/03/17 14:54, Guido Medina wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> I have an issue now with my dynamic FIX acceptor, if I disconnect a session from the server and
> enable it again, the client is able to reconnect, but if the initiator disconnects and try to
> connect again it constantly stays on the Logon, Disconnect cycle.
>
> It seems like if the session encounters a END_OF_STREAM it cannot connect again.
> How to properly clean a disconnected session from the acceptor? Help appreciate, I have been
> debugging for hours now and no luck.
>
> Best regards,
>
> Guido.
--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[hidden email]
       


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Oh I see, you overwrite getSession (carefully) and return null, you will be disconnected automatically because session is not found.
Don't worry I understand how you would do it, I have seen the source code and contributed my bits to QFJ ;-)

Both ideas are good, I think it will be a matter of convenience on what to use: RejectLogon exception vs returning null.

Thanks a lot for the idea.

Guido.

On Mon, Jan 30, 2017 at 3:05 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I don't have an example for 1.7, but this one works on 1.6.3.

public class DynamicAcceptorSessionProvider
        implements AcceptorSessionProvider
{
...
    @Override
    public Session getSession(SessionID inSessionId,
                              SessionConnector inConnector)
    {
        String sessionName = brokerService.getSessionName(inSessionId);
        // first, check to see if the session already exists
        Session session = Session.lookupSession(inSessionId);
        if(session != null) {
            return session;
        }
        // session doesn't exist yet, check to see if there's a session that matches in the DB
        FixSession fixSession = brokerService.findFixSessionBySessionId(inSessionId);
        if(fixSession == null) {
            return null;
        }
...
    }

I can't remember from the top of my head why/how returning null works. We have a list of preauthorized sessions in the db which we validate against.

Hope this helps.

- Colin

On 01/29/2017 12:53 PM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi,

I wonder if there is an example where I can see an acceptor that authenticates the initiator via DB so that the session is NOT created if the authentication fails, also, any sender and target comp Id because the DB is what will tell if such session can be created.

I have been trying to dynamic sessions but somehow not working for QFJ 1.7.x (released internally)

Thanks a lot for any help, pointers/links, etc.

Guido.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIX acceptor

Colin DuPlantis
In reply to this post by Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Are you having sequence number issues? Does one side but not the other reset the sequence number on disconnect?

For us, our system has the ability to delete a session without restarting the application. We had to explicitly remove the session from the acceptor.

We extend ThreadedSocketAcceptor and add this in addition to the constructors you have to override:

    @Override
    public void removeDynamicSession(SessionID inSessionId)
    {
        String sessionName = sessionServices.getSessionName(inSessionId);
        Session existingSession = Session.lookupSession(inSessionId);
        SLF4JLoggerProxy.debug(this,
                               "Removing dynamic session {}, existing session: {}",
                               sessionName,
                               existingSession);
   
    super.removeDynamicSession(inSessionId);
        if(existingSession != null) {
            SLF4JLoggerProxy.debug(this,
                                   "Logging {} out",
                                   sessionName);
            try {
                existingSession.logout();
            } catch (Exception e) {
                SLF4JLoggerProxy.warn(this,
                                      e);
            }
            if(existingSession.isLoggedOn()) {
                SLF4JLoggerProxy.debug(this,
                                       "Forcing {} disconnect",
                                       sessionName);
                try {
                    existingSession.disconnect("Session removed",
                                               false);
                } catch (Exception e) {
                    SLF4JLoggerProxy.warn(this,
                                          e);
                }
            }
            SLF4JLoggerProxy.debug(this,
                                   "Unregistering {}",
                                   sessionName);
 ==>        Session.unregisterSessions(Lists.newArrayList(inSessionId));
            if(Session.lookupSession(inSessionId) == null) {
                SLF4JLoggerProxy.debug(this,
                                       "{} succesfully unregistered",
                                       sessionName);
            } else {
                SLF4JLoggerProxy.debug(this,
                                       "{} unsuccesfully unregistered",
                                       sessionName);
            }
        }
    }


On 03/03/2017 05:54 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




I have an issue now with my dynamic FIX acceptor, if I disconnect a session from the server and enable it again, the client is able to reconnect, but if the initiator disconnects and try to connect again it constantly stays on the Logon, Disconnect cycle.

It seems like if the session encounters a END_OF_STREAM it cannot connect again.
How to properly clean a disconnected session from the acceptor? Help appreciate, I have been debugging for hours now and no luck.

Best regards,

Guido.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIX acceptor

Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Yes, this is related, basically if an initiator disconnects from my acceptor, it cannot reconnect again, here is the log:

INFO  14:29:09,448 AcceptorIoHandler - MINA session created: local=/127.0.0.1:10081, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/127.0.0.1:34471
INFO  14:29:09,475 event - FIX.4.4:target->sender: Accepting session FIX.4.4:target->sender from /127.0.0.1:34471
INFO  14:29:09,475 event - FIX.4.4:target->sender: Acceptor heartbeat set to 30 seconds
INFO  14:29:09,475 event - FIX.4.4:target->sender: Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1
INFO  14:29:09,478 TargetSupervisor - FIX acceptor received login message: 8=FIX.4.4|9=90|35=A|34=1|49=sender|52=20170303-14:29:09.435|56=target|98=0|108=30|141=Y|554=GyEXDay8FWld|10=053|
INFO  14:29:09,494 event - FIX.4.4:target->sender: Received logon
INFO  14:29:09,494 event - FIX.4.4:target->sender: Responding to Logon request
INFO  14:29:09,501 TargetSupervisor - Command{action=CREATE_CHILD, key=null, value=ChildKey{type=SupervisorType{name=TARGET, dist=SHARD}, id='15'}}
INFO  14:29:09,504 TargetSupervisor - Logged in session ID 'FIX.4.4:target->sender'
INFO  14:29:09,504 event - FIX.4.4:target->sender: Initiated logout request
INFO  14:29:09,533 event - FIX.4.4:target->sender: Received logout response
INFO  14:29:09,533 Session - [FIX.4.4:target->sender] Disconnecting: Received logout response
WARN  14:29:09,533 TargetSupervisor - Received logout for session ID: FIX.4.4:target->sender
INFO  14:29:09,534 PriceFixAcceptor - Price FIX acceptor ended for session ID: 'FIX.4.4:target->sender'

It seems that the session is marked as logout once after the 1st logout, that doesn't happen if the FIX acceptor logs log the session,
I have some idea, maybe I'm calling session.logout() after the logout happend when the initiator disconnects? and before when the acceptor disconnects?

WDYT?

Guido.

On Fri, Mar 3, 2017 at 2:14 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Are you having sequence number issues? Does one side but not the other reset the sequence number on disconnect?

For us, our system has the ability to delete a session without restarting the application. We had to explicitly remove the session from the acceptor.

We extend ThreadedSocketAcceptor and add this in addition to the constructors you have to override:

    @Override
    public void removeDynamicSession(SessionID inSessionId)
    {
        String sessionName = sessionServices.getSessionName(inSessionId);
        Session existingSession = Session.lookupSession(inSessionId);
        SLF4JLoggerProxy.debug(this,
                               "Removing dynamic session {}, existing session: {}",
                               sessionName,
                               existingSession);
   
    super.removeDynamicSession(inSessionId);
        if(existingSession != null) {
            SLF4JLoggerProxy.debug(this,
                                   "Logging {} out",
                                   sessionName);
            try {
                existingSession.logout();
            } catch (Exception e) {
                SLF4JLoggerProxy.warn(this,
                                      e);
            }
            if(existingSession.isLoggedOn()) {
                SLF4JLoggerProxy.debug(this,
                                       "Forcing {} disconnect",
                                       sessionName);
                try {
                    existingSession.disconnect("Session removed",
                                               false);
                } catch (Exception e) {
                    SLF4JLoggerProxy.warn(this,
                                          e);
                }
            }
            SLF4JLoggerProxy.debug(this,
                                   "Unregistering {}",
                                   sessionName);
 ==>        Session.unregisterSessions(Lists.newArrayList(inSessionId));
            if(Session.lookupSession(inSessionId) == null) {
                SLF4JLoggerProxy.debug(this,
                                       "{} succesfully unregistered",
                                       sessionName);
            } else {
                SLF4JLoggerProxy.debug(this,
                                       "{} unsuccesfully unregistered",
                                       sessionName);
            }
        }
    }


On 03/03/2017 05:54 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




I have an issue now with my dynamic FIX acceptor, if I disconnect a session from the server and enable it again, the client is able to reconnect, but if the initiator disconnects and try to connect again it constantly stays on the Logon, Disconnect cycle.

It seems like if the session encounters a END_OF_STREAM it cannot connect again.
How to properly clean a disconnected session from the acceptor? Help appreciate, I have been debugging for hours now and no luck.

Best regards,

Guido.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIX acceptor

Colin DuPlantis
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



What QFJ version are you using?



On 03/03/2017 06:33 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Yes, this is related, basically if an initiator disconnects from my acceptor, it cannot reconnect again, here is the log:

INFO  14:29:09,448 AcceptorIoHandler - MINA session created: local=/127.0.0.1:10081, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/127.0.0.1:34471
INFO  14:29:09,475 event - FIX.4.4:target->sender: Accepting session FIX.4.4:target->sender from /127.0.0.1:34471
INFO  14:29:09,475 event - FIX.4.4:target->sender: Acceptor heartbeat set to 30 seconds
INFO  14:29:09,475 event - FIX.4.4:target->sender: Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1
INFO  14:29:09,478 TargetSupervisor - FIX acceptor received login message: 8=FIX.4.4|9=90|35=A|34=1|49=sender|52=20170303-14:29:09.435|56=target|98=0|108=30|141=Y|554=GyEXDay8FWld|10=053|
INFO  14:29:09,494 event - FIX.4.4:target->sender: Received logon
INFO  14:29:09,494 event - FIX.4.4:target->sender: Responding to Logon request
INFO  14:29:09,501 TargetSupervisor - Command{action=CREATE_CHILD, key=null, value=ChildKey{type=SupervisorType{name=TARGET, dist=SHARD}, id='15'}}
INFO  14:29:09,504 TargetSupervisor - Logged in session ID 'FIX.4.4:target->sender'
INFO  14:29:09,504 event - FIX.4.4:target->sender: Initiated logout request
INFO  14:29:09,533 event - FIX.4.4:target->sender: Received logout response
INFO  14:29:09,533 Session - [FIX.4.4:target->sender] Disconnecting: Received logout response
WARN  14:29:09,533 TargetSupervisor - Received logout for session ID: FIX.4.4:target->sender
INFO  14:29:09,534 PriceFixAcceptor - Price FIX acceptor ended for session ID: 'FIX.4.4:target->sender'

It seems that the session is marked as logout once after the 1st logout, that doesn't happen if the FIX acceptor logs log the session,
I have some idea, maybe I'm calling session.logout() after the logout happend when the initiator disconnects? and before when the acceptor disconnects?

WDYT?

Guido.

On Fri, Mar 3, 2017 at 2:14 PM, Colin DuPlantis <[hidden email]> wrote:

Are you having sequence number issues? Does one side but not the other reset the sequence number on disconnect?

For us, our system has the ability to delete a session without restarting the application. We had to explicitly remove the session from the acceptor.

We extend ThreadedSocketAcceptor and add this in addition to the constructors you have to override:

    @Override
    public void removeDynamicSession(SessionID inSessionId)
    {
        String sessionName = sessionServices.getSessionName(inSessionId);
        Session existingSession = Session.lookupSession(inSessionId);
        SLF4JLoggerProxy.debug(this,
                               "Removing dynamic session {}, existing session: {}",
                               sessionName,
                               existingSession);
   
    super.removeDynamicSession(inSessionId);
        if(existingSession != null) {
            SLF4JLoggerProxy.debug(this,
                                   "Logging {} out",
                                   sessionName);
            try {
                existingSession.logout();
            } catch (Exception e) {
                SLF4JLoggerProxy.warn(this,
                                      e);
            }
            if(existingSession.isLoggedOn()) {
                SLF4JLoggerProxy.debug(this,
                                       "Forcing {} disconnect",
                                       sessionName);
                try {
                    existingSession.disconnect("Session removed",
                                               false);
                } catch (Exception e) {
                    SLF4JLoggerProxy.warn(this,
                                          e);
                }
            }
            SLF4JLoggerProxy.debug(this,
                                   "Unregistering {}",
                                   sessionName);
 ==>        Session.unregisterSessions(Lists.newArrayList(inSessionId));
            if(Session.lookupSession(inSessionId) == null) {
                SLF4JLoggerProxy.debug(this,
                                       "{} succesfully unregistered",
                                       sessionName);
            } else {
                SLF4JLoggerProxy.debug(this,
                                       "{} unsuccesfully unregistered",
                                       sessionName);
            }
        }
    }


On 03/03/2017 05:54 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I have an issue now with my dynamic FIX acceptor, if I disconnect a session from the server and enable it again, the client is able to reconnect, but if the initiator disconnects and try to connect again it constantly stays on the Logon, Disconnect cycle.
It seems like if the session encounters a END_OF_STREAM it cannot connect again.
How to properly clean a disconnected session from the acceptor? Help appreciate, I have been debugging for hours now and no luck.
Best regards,
Guido.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIX acceptor

Guido Medina
In reply to this post by Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I made too many syntantic english errors, correction:

If I logout the session via FIX acceptor, it can reconnect again, if I logout the session via initiator it cannot connect again,
that is because the session object is shared and when I logout via FIX acceptor, the session is market as logout,
when I logout from the initiator, onLogout() sends a message to another guy which marks the session as logout.

That to try to always logout the session if either your user is disabled or if your initiator disconnects,
so I think I'm marking the reusable -and cached- session as logout hence next login will logout.

That's what I think is happening, because my system is developed in Akka and all happens asynchronously.

Regards,

Guido.

On Fri, Mar 3, 2017 at 2:33 PM, Guido Medina <[hidden email]> wrote:
Yes, this is related, basically if an initiator disconnects from my acceptor, it cannot reconnect again, here is the log:

INFO  14:29:09,448 AcceptorIoHandler - MINA session created: local=/127.0.0.1:10081, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/127.0.0.1:34471
INFO  14:29:09,475 event - FIX.4.4:target->sender: Accepting session FIX.4.4:target->sender from /127.0.0.1:34471
INFO  14:29:09,475 event - FIX.4.4:target->sender: Acceptor heartbeat set to 30 seconds
INFO  14:29:09,475 event - FIX.4.4:target->sender: Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1
INFO  14:29:09,478 TargetSupervisor - FIX acceptor received login message: 8=FIX.4.4|9=90|35=A|34=1|49=sender|52=20170303-14:29:09.435|56=target|98=0|108=30|141=Y|554=GyEXDay8FWld|10=053|
INFO  14:29:09,494 event - FIX.4.4:target->sender: Received logon
INFO  14:29:09,494 event - FIX.4.4:target->sender: Responding to Logon request
INFO  14:29:09,501 TargetSupervisor - Command{action=CREATE_CHILD, key=null, value=ChildKey{type=SupervisorType{name=TARGET, dist=SHARD}, id='15'}}
INFO  14:29:09,504 TargetSupervisor - Logged in session ID 'FIX.4.4:target->sender'
INFO  14:29:09,504 event - FIX.4.4:target->sender: Initiated logout request
INFO  14:29:09,533 event - FIX.4.4:target->sender: Received logout response
INFO  14:29:09,533 Session - [FIX.4.4:target->sender] Disconnecting: Received logout response
WARN  14:29:09,533 TargetSupervisor - Received logout for session ID: FIX.4.4:target->sender
INFO  14:29:09,534 PriceFixAcceptor - Price FIX acceptor ended for session ID: 'FIX.4.4:target->sender'

It seems that the session is marked as logout once after the 1st logout, that doesn't happen if the FIX acceptor logs log the session,
I have some idea, maybe I'm calling session.logout() after the logout happend when the initiator disconnects? and before when the acceptor disconnects?

WDYT?

Guido.

On Fri, Mar 3, 2017 at 2:14 PM, Colin DuPlantis <[hidden email]> wrote:

Are you having sequence number issues? Does one side but not the other reset the sequence number on disconnect?

For us, our system has the ability to delete a session without restarting the application. We had to explicitly remove the session from the acceptor.

We extend ThreadedSocketAcceptor and add this in addition to the constructors you have to override:

    @Override
    public void removeDynamicSession(SessionID inSessionId)
    {
        String sessionName = sessionServices.getSessionName(inSessionId);
        Session existingSession = Session.lookupSession(inSessionId);
        SLF4JLoggerProxy.debug(this,
                               "Removing dynamic session {}, existing session: {}",
                               sessionName,
                               existingSession);
   
    super.removeDynamicSession(inSessionId);
        if(existingSession != null) {
            SLF4JLoggerProxy.debug(this,
                                   "Logging {} out",
                                   sessionName);
            try {
                existingSession.logout();
            } catch (Exception e) {
                SLF4JLoggerProxy.warn(this,
                                      e);
            }
            if(existingSession.isLoggedOn()) {
                SLF4JLoggerProxy.debug(this,
                                       "Forcing {} disconnect",
                                       sessionName);
                try {
                    existingSession.disconnect("Session removed",
                                               false);
                } catch (Exception e) {
                    SLF4JLoggerProxy.warn(this,
                                          e);
                }
            }
            SLF4JLoggerProxy.debug(this,
                                   "Unregistering {}",
                                   sessionName);
 ==>        Session.unregisterSessions(Lists.newArrayList(inSessionId));
            if(Session.lookupSession(inSessionId) == null) {
                SLF4JLoggerProxy.debug(this,
                                       "{} succesfully unregistered",
                                       sessionName);
            } else {
                SLF4JLoggerProxy.debug(this,
                                       "{} unsuccesfully unregistered",
                                       sessionName);
            }
        }
    }


On 03/03/2017 05:54 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




I have an issue now with my dynamic FIX acceptor, if I disconnect a session from the server and enable it again, the client is able to reconnect, but if the initiator disconnects and try to connect again it constantly stays on the Logon, Disconnect cycle.

It seems like if the session encounters a END_OF_STREAM it cannot connect again.
How to properly clean a disconnected session from the acceptor? Help appreciate, I have been debugging for hours now and no luck.

Best regards,

Guido.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIX acceptor

Guido Medina
In reply to this post by Colin DuPlantis
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Colin,

I'm using a custom 1.7.x (current master) build, should be equivalent to 1.6.latest, I will do some experiments and let you know.

Regards,

Guido.

On Fri, Mar 3, 2017 at 2:14 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Are you having sequence number issues? Does one side but not the other reset the sequence number on disconnect?

For us, our system has the ability to delete a session without restarting the application. We had to explicitly remove the session from the acceptor.

We extend ThreadedSocketAcceptor and add this in addition to the constructors you have to override:

    @Override
    public void removeDynamicSession(SessionID inSessionId)
    {
        String sessionName = sessionServices.getSessionName(inSessionId);
        Session existingSession = Session.lookupSession(inSessionId);
        SLF4JLoggerProxy.debug(this,
                               "Removing dynamic session {}, existing session: {}",
                               sessionName,
                               existingSession);
   
    super.removeDynamicSession(inSessionId);
        if(existingSession != null) {
            SLF4JLoggerProxy.debug(this,
                                   "Logging {} out",
                                   sessionName);
            try {
                existingSession.logout();
            } catch (Exception e) {
                SLF4JLoggerProxy.warn(this,
                                      e);
            }
            if(existingSession.isLoggedOn()) {
                SLF4JLoggerProxy.debug(this,
                                       "Forcing {} disconnect",
                                       sessionName);
                try {
                    existingSession.disconnect("Session removed",
                                               false);
                } catch (Exception e) {
                    SLF4JLoggerProxy.warn(this,
                                          e);
                }
            }
            SLF4JLoggerProxy.debug(this,
                                   "Unregistering {}",
                                   sessionName);
 ==>        Session.unregisterSessions(Lists.newArrayList(inSessionId));
            if(Session.lookupSession(inSessionId) == null) {
                SLF4JLoggerProxy.debug(this,
                                       "{} succesfully unregistered",
                                       sessionName);
            } else {
                SLF4JLoggerProxy.debug(this,
                                       "{} unsuccesfully unregistered",
                                       sessionName);
            }
        }
    }


On 03/03/2017 05:54 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




I have an issue now with my dynamic FIX acceptor, if I disconnect a session from the server and enable it again, the client is able to reconnect, but if the initiator disconnects and try to connect again it constantly stays on the Logon, Disconnect cycle.

It seems like if the session encounters a END_OF_STREAM it cannot connect again.
How to properly clean a disconnected session from the acceptor? Help appreciate, I have been debugging for hours now and no luck.

Best regards,

Guido.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIX acceptor

Colin DuPlantis
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Based on the log you sent, here's the place where the logout is generated in Session.java:

    public void next() throws IOException {

        if (!isEnabled()) {
            if (isLoggedOn()) {
                if (!state.isLogoutSent()) {
                    getLog().onEvent("Initiated logout request");
                    generateLogout(state.getLogoutReason());

This gives you three things to look at in the Session.

While the fix I sent in the code may work because it will essentially nuke the in-memory state of the Session, I don't think that's the right fix for you. I think you need to look at how the Session state changes.


On 03/03/2017 06:44 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi Colin,

I'm using a custom 1.7.x (current master) build, should be equivalent to 1.6.latest, I will do some experiments and let you know.

Regards,

Guido.

On Fri, Mar 3, 2017 at 2:14 PM, Colin DuPlantis <[hidden email]> wrote:

Are you having sequence number issues? Does one side but not the other reset the sequence number on disconnect?

For us, our system has the ability to delete a session without restarting the application. We had to explicitly remove the session from the acceptor.

We extend ThreadedSocketAcceptor and add this in addition to the constructors you have to override:

    @Override
    public void removeDynamicSession(SessionID inSessionId)
    {
        String sessionName = sessionServices.getSessionName(inSessionId);
        Session existingSession = Session.lookupSession(inSessionId);
        SLF4JLoggerProxy.debug(this,
                               "Removing dynamic session {}, existing session: {}",
                               sessionName,
                               existingSession);
   
    super.removeDynamicSession(inSessionId);
        if(existingSession != null) {
            SLF4JLoggerProxy.debug(this,
                                   "Logging {} out",
                                   sessionName);
            try {
                existingSession.logout();
            } catch (Exception e) {
                SLF4JLoggerProxy.warn(this,
                                      e);
            }
            if(existingSession.isLoggedOn()) {
                SLF4JLoggerProxy.debug(this,
                                       "Forcing {} disconnect",
                                       sessionName);
                try {
                    existingSession.disconnect("Session removed",
                                               false);
                } catch (Exception e) {
                    SLF4JLoggerProxy.warn(this,
                                          e);
                }
            }
            SLF4JLoggerProxy.debug(this,
                                   "Unregistering {}",
                                   sessionName);
 ==>        Session.unregisterSessions(Lists.newArrayList(inSessionId));
            if(Session.lookupSession(inSessionId) == null) {
                SLF4JLoggerProxy.debug(this,
                                       "{} succesfully unregistered",
                                       sessionName);
            } else {
                SLF4JLoggerProxy.debug(this,
                                       "{} unsuccesfully unregistered",
                                       sessionName);
            }
        }
    }


On 03/03/2017 05:54 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I have an issue now with my dynamic FIX acceptor, if I disconnect a session from the server and enable it again, the client is able to reconnect, but if the initiator disconnects and try to connect again it constantly stays on the Logon, Disconnect cycle.
It seems like if the session encounters a END_OF_STREAM it cannot connect again.
How to properly clean a disconnected session from the acceptor? Help appreciate, I have been debugging for hours now and no luck.
Best regards,
Guido.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FIX acceptor

Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Yeap, what I did fixed it, basically, if I received the logout from the onLogout I send a message to the actor not to mark the session as logout such thing already happened,
if I send a message to the actor then it marks the session and disconnect normally.

Either way, I can reconnect now.

Thanks for the tips,

Guido.

On Fri, Mar 3, 2017 at 2:48 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Based on the log you sent, here's the place where the logout is generated in Session.java:

    public void next() throws IOException {

        if (!isEnabled()) {
            if (isLoggedOn()) {
                if (!state.isLogoutSent()) {
                    getLog().onEvent("Initiated logout request");
                    generateLogout(state.getLogoutReason());

This gives you three things to look at in the Session.

While the fix I sent in the code may work because it will essentially nuke the in-memory state of the Session, I don't think that's the right fix for you. I think you need to look at how the Session state changes.


On 03/03/2017 06:44 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi Colin,

I'm using a custom 1.7.x (current master) build, should be equivalent to 1.6.latest, I will do some experiments and let you know.

Regards,

Guido.

On Fri, Mar 3, 2017 at 2:14 PM, Colin DuPlantis <[hidden email]> wrote:

Are you having sequence number issues? Does one side but not the other reset the sequence number on disconnect?

For us, our system has the ability to delete a session without restarting the application. We had to explicitly remove the session from the acceptor.

We extend ThreadedSocketAcceptor and add this in addition to the constructors you have to override:

    @Override
    public void removeDynamicSession(SessionID inSessionId)
    {
        String sessionName = sessionServices.getSessionName(inSessionId);
        Session existingSession = Session.lookupSession(inSessionId);
        SLF4JLoggerProxy.debug(this,
                               "Removing dynamic session {}, existing session: {}",
                               sessionName,
                               existingSession);
   
    super.removeDynamicSession(inSessionId);
        if(existingSession != null) {
            SLF4JLoggerProxy.debug(this,
                                   "Logging {} out",
                                   sessionName);
            try {
                existingSession.logout();
            } catch (Exception e) {
                SLF4JLoggerProxy.warn(this,
                                      e);
            }
            if(existingSession.isLoggedOn()) {
                SLF4JLoggerProxy.debug(this,
                                       "Forcing {} disconnect",
                                       sessionName);
                try {
                    existingSession.disconnect("Session removed",
                                               false);
                } catch (Exception e) {
                    SLF4JLoggerProxy.warn(this,
                                          e);
                }
            }
            SLF4JLoggerProxy.debug(this,
                                   "Unregistering {}",
                                   sessionName);
 ==>        Session.unregisterSessions(Lists.newArrayList(inSessionId));
            if(Session.lookupSession(inSessionId) == null) {
                SLF4JLoggerProxy.debug(this,
                                       "{} succesfully unregistered",
                                       sessionName);
            } else {
                SLF4JLoggerProxy.debug(this,
                                       "{} unsuccesfully unregistered",
                                       sessionName);
            }
        }
    }


On 03/03/2017 05:54 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I have an issue now with my dynamic FIX acceptor, if I disconnect a session from the server and enable it again, the client is able to reconnect, but if the initiator disconnects and try to connect again it constantly stays on the Logon, Disconnect cycle.
It seems like if the session encounters a END_OF_STREAM it cannot connect again.
How to properly clean a disconnected session from the acceptor? Help appreciate, I have been debugging for hours now and no luck.
Best regards,
Guido.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Loading...