[Quickfixj-users] acceptor restart issue

[Robert B. <rbr...@me...>]

We're noticing a pretty regular issue with one of our vendors who
require us to be an acceptor for their message flow:  If we fire up the
acceptor...their first attempt to connect to us results is our acceptor
sending them a logout message.  Their second attempt succeeds and
message flow commences...if we leave this instance up and running for
any length of time, the session ends at 8 pm, logs out and then the
session starts up again the next day at 7:30 am without a hitch on
either end.=20=20

=20

If for some reason after 8 pm, whether it be database or log maintenance
or something and the DBA has to stop the acceptor instance (last night
he shut it down at 1:35 am as shown below), the log shows the following:

=20

----

=20

2007-09-26 20:05:05,062 DEBUG [QF/J Session dispatcher:
FIX.4.2:US->THEM] fix.Application (?:?) - logging off...

=20

Terminated by runtime system.  Shutting down FIX server.

=20

Sep 27, 2007 1:35:37 AM quickfix.mina.acceptor.AbstractSocketAcceptor
stopAcceptingConnections

=20

INFO: No longer accepting connections on /x.x.x.x:4321

=20

Sep 27, 2007 1:35:37 AM quickfix.mina.SessionConnector logoutAllSessions

=20

INFO: Logging out all sessions

=20

----

=20

So by all appearances, we're validly logging out with the vendor at 8 pm
and then I have a shutdown hook that captures any os-level process
termination that in turn double-checks and validly logs out of all
sessions still active before completely killing the process.

=20

We fired it back up at 4:35 am this morning...and 7:30 am rolls
around...the log shows the following:

=20

----

=20

Sep 27, 2007 4:28:39 AM quickfix.mina.acceptor.AbstractSocketAcceptor
startAcceptingConnections

=20

INFO: Listening for connections at /x.x.x.x:4321

=20

Sep 27, 2007 7:30:05 AM quickfix.mina.acceptor.AcceptorIoHandler
sessionCreated

=20

INFO: MINA session created: /x.x.x.x:15071

=20

Sep 27, 2007 7:30:15 AM quickfix.mina.acceptor.AcceptorIoHandler
sessionCreated

=20

INFO: MINA session created: /x.x.x.x:15071

=20

2007-09-27 07:30:20,042 DEBUG [SocketAcceptorIoProcessor-0.0]
fix.Application (?:?) - logging off...

=20

----

=20

It almost looks like they try to connect twice in a row at 7:30:05 and
7:30:15 but regardless of how many times they attempt to connect, it
always results in us logging off and sending them a logout message in
response to the login message they send to us.

=20

But like I said, if we hadn't restarted the instance, and just left it
up and running, when they attempt to establish the session the next day,
there are no problems at all.

=20

Does anyone see anything by looking at these bare-bones log messages?
Does anyone have any ideas what could be causing this ONLY when we
restart the instance?  I mean it's not the end of the world since I send
the vendor an email and they attempt to reconnect again and the message
flow starts up again...but I would like not to have to involve anyone
and be able to gracefully restart the acceptor without impacting the
production system at all.

=20

Any help would be greatly appreciated.

=20

Thanks,

Merlin Securities - #1 Prime Broker North America, #1 Prime Broker Single S=
trategy Funds, #1 Prime Broker Funds Under $100M - Global Custodian 2007


=20

--------------------------------------------------------

This message contains information from Merlin Securities, LLC, or from one =
of its affiliates, that may be confidential and privileged. If you are not =
an intended recipient, please refrain from any disclosure, copying, distrib=
ution or use of this information and note that such actions are prohibited.=
 If you have received this transmission in error, please notify the sender =
immediately by telephone or by replying to this transmission.
=20
Merlin Securities, LLC is a registered broker-dealer. Services offered thro=
ugh Merlin Securities, LLC are not insured by the FDIC or any other Federal=
 Government Agency, are not deposits of or guaranteed by Merlin Securities,=
 LLC and may lose value. Nothing in this communication shall constitute a s=
olicitation or recommendation to buy or sell a particular security.