QuickfixJ Initiator reconnection policy & SeqNum Resets

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

QuickfixJ Initiator reconnection policy & SeqNum Resets

truesaint
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Hello again, everyone :)

As per the subject, i'm wondering about QuickfixJ reconnection policy
(for initiators). Suppose an Initiator got disconnected (for whatever
reason: network problems, power problems, hardware problems,
acceptor/server maintenance, etc), what's gonna happen next ?

There were mentions about 'ReconnectInterval' parameter in the config
file; does it mean that the initiator will retry to reconnect
indefinitely? Is the mechanism reliable ?

I couldn't make it work (with a third party server, so i don't know much
about the implementation details on their side) during my earlier tests,
so i resorted to using a background thread to create another instance of
the initiator when it detected any problems with the current one. This
approach worked fine so far, with a rather nasty catch.

This morning, the initiator failed to reconnect after the normal
maintenance downtime during the weekend. Apparently the server/acceptor
did a seqnum reset during the maintenance period since the log contains
errors similar to these :
...
quickfix.SessionException MsgSeqNum too low,
expecting 1793530 but received 11797
...

Then i found some configuration parameters ('ResetOnDisconnect' and
'ResetOnLogout') which seems to be the answer, but enabling this on my
current implementation gave several 'File Delete Failed' error messages,
probably because the file is still open/used at this time.

So, after the long rambling, i suppose the question is: How do i reset
the seqnum ? :) Or am i supposed to use something other than a FileStore ?

Thanks in advance,
regards,
t.s.

PS: I found an older thread about something similar from a couple of
weeks ago, with the subject of "Initiator.Stop leaves file handles open
when using FileStore", but i'm not sure i understand the conclusion...































-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: QuickfixJ Initiator reconnection policy & SeqNumResets

Rob McConnell
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
If you want to implement a re-connection strategy using FileStore,
you'll have to cleanup the files yourself. Quickfix doesn't close its
message files or log files when you do initiator.stop().

I got round this by casting

MessageStore store = session.getStore();
if (store instanceof FileStore) {
        ((FileStore) store).closeFiles();
}
   
However for log files you will need to implement your own LogFactory and
Log that allows you to close files.

Rob

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of t.s.
Sent: 11 June 2007 05:56
To: [hidden email]
Subject: [Quickfixj-users] QuickfixJ Initiator reconnection policy &
SeqNumResets

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Hello again, everyone :)

As per the subject, i'm wondering about QuickfixJ reconnection policy
(for initiators). Suppose an Initiator got disconnected (for whatever
reason: network problems, power problems, hardware problems,
acceptor/server maintenance, etc), what's gonna happen next ?

There were mentions about 'ReconnectInterval' parameter in the config
file; does it mean that the initiator will retry to reconnect
indefinitely? Is the mechanism reliable ?

I couldn't make it work (with a third party server, so i don't know much
about the implementation details on their side) during my earlier tests,
so i resorted to using a background thread to create another instance of
the initiator when it detected any problems with the current one. This
approach worked fine so far, with a rather nasty catch.

This morning, the initiator failed to reconnect after the normal
maintenance downtime during the weekend. Apparently the server/acceptor
did a seqnum reset during the maintenance period since the log contains
errors similar to these :
...
quickfix.SessionException MsgSeqNum too low,
expecting 1793530 but received 11797
...

Then i found some configuration parameters ('ResetOnDisconnect' and
'ResetOnLogout') which seems to be the answer, but enabling this on my
current implementation gave several 'File Delete Failed' error messages,
probably because the file is still open/used at this time.

So, after the long rambling, i suppose the question is: How do i reset
the seqnum ? :) Or am i supposed to use something other than a FileStore
?

Thanks in advance,
regards,
t.s.

PS: I found an older thread about something similar from a couple of
weeks ago, with the subject of "Initiator.Stop leaves file handles open
when using FileStore", but i'm not sure i understand the conclusion...































------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail.

Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited.  If you receive this transmission in error, please notify us immediately, and then delete this E-mail.

Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan any attachments.

Eurobase Systems Limited is the main trading company in the Eurobase International Group; registered in England and Wales as company number 02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex CM2 0RE, UK.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: QuickfixJ Initiator reconnection policy & SeqNumResets

Stephen Bate
In reply to this post by truesaint
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
> t.s. wrote:
> As per the subject, i'm wondering about QuickfixJ reconnection policy
> (for initiators). Suppose an Initiator got disconnected (for whatever
> reason: network problems, power problems, hardware problems,
> acceptor/server maintenance, etc), what's gonna happen next ?

A QFJ initiator will periodically attempt to reconnect. Once a connection
is established, the initiator will attempt to login with the counterparty.

You can see this behavior with the Banzai (client) and Executor (server)
examples in the QFJ distribution. Start Banzai first and you will see
it trying to connect periodically. Start the Executor and you will see
Banzai connect. Stop the executor and Banzai will start trying to
connect again.
 
> There were mentions about 'ReconnectInterval' parameter in the config
> file; does it mean that the initiator will retry to reconnect
> indefinitely? Is the mechanism reliable ?

Yes, it will reconnect indefinitely. And it's reliable as far as I
know. What problems were you experiencing?

> I couldn't make it work (with a third party server, so i don't know much
> about the implementation details on their side) during my earlier tests,
> so i resorted to using a background thread to create another instance of
> the initiator when it detected any problems with the current one. This
> approach worked fine so far, with a rather nasty catch.

I strongly recommend using the built-in reconnection capabilities instead
of this approach. It might work to some extent, but the initiators are not
designed to be used this way.

Steve





-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: QuickfixJ Initiator reconnection policy & SeqNumResets

truesaint
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Sorry for late reply,

>> There were mentions about 'ReconnectInterval' parameter in the config
>> file; does it mean that the initiator will retry to reconnect
>> indefinitely? Is the mechanism reliable ?
> Yes, it will reconnect indefinitely. And it's reliable as far as I
> know. What problems were you experiencing?
The first version that i deployed on the remote machine uses only a
single thread/instance of the initiator. There were complaints from the
users that the initiator failed to reconnect to third party server in
several scenarios :
1. connection is broken by the remote server on purpose. (maintenance)
2. internet connection problem (we have a rather spotty infrastructure)
3. unplugging the network cable from the machine. (a bit extreme, i
know...:)

Because of time constraints, i ended up with the approach i mentioned
earlier: dropping the whole thread/instance and creating another one
from scratch as soon as any problem's detected. It's been running OK for
several weeks now, but it does seem a bit overkill...

> I strongly recommend using the built-in reconnection capabilities instead
> of this approach. It might work to some extent, but the initiators are not
> designed to be used this way.
I see. I will try going back to the single instance approach. Thanks for
the suggestion. I'll let you know how it goes.

Concerning the sequence number reset thingy, i just got confirmation
that i'm supposed to send a tag 141=Y value in the logon message via the
toAdmin() method.
...
   message.setField(new ResetSeqNumFlag(true) );
...

Do i have to do anything else for quickfix/j to negotiate the sequence
number reset ?

Thanks in advance,
regards,
t.s.










-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users