[QFJ-697] Unable to restart a stopped acceptor (SocketAcceptor) -- still exists Created: 08/Aug/12  Updated: 08/Aug/12  Resolved: 08/Aug/12

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.5.0, 1.5.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mate Varga Assignee: Christoph John
Resolution: Duplicate Votes: 0
Labels: None


 Description   

This is a similar issue as in QFJ-348 but for acceptors.

When I do acceptor.start() QF/J says:

Listening for connections at 0.0.0.0/0.0.0.0:10040

netstat output:

tcp6       0      0 :::10040                :::*                    LISTEN

After a stop() and another start(), the acceptor does not print the usual "Listening... at" information and also the netstat output is not listing the port.

A workaround could be to re-create the acceptor. But this is somewhat unexpected since we have start() and stop() methods.

If I interpret the code in the SocketAcceptor.class correctly, all that is needed is to set the "isStarted" flag to FALSE again on a stop(). This would trigger the call of the method "startAcceptingConnections()" on the next start() call. Could someone with more insight into the code please comment on this?

Thanks in advance,
Chris.

 Comments   
Comment by Mate Varga [ 08/Aug/12 ]

The problem still exists.

AbstractSocketAcceptor creates the sessions in it's constructor:

[...]
protected AbstractSocketAcceptor(SessionSettings settings, SessionFactory sessionFactory)
throws ConfigError {
super(settings, sessionFactory);
ByteBuffer.setAllocator(new SimpleByteBufferAllocator());
ByteBuffer.setUseDirectBuffers(false);
this.sessionFactory = sessionFactory;
try {
createSessions(settings); // !!!!!
[...]

... but SocketAcceptors unregister them in their stop() method:

public void stop(boolean forceDisconnect) {
eventHandlingStrategy.stopHandlingMessages();
stopAcceptingConnections();
logoutAllSessions(forceDisconnect);
stopSessionTimer();
Session.unregisterSessions(getSessions()); // !!!!

... and do not re-register them in their 'start' method.

The most probable solution is to re-register sessions in 'start', if they have been unregistered.

Comment by Mate Varga [ 08/Aug/12 ]

Hm, this seems to be fixed in 1.5.2. Apologies for reopening, I was probably looking at the wrong source – please close the issue.

Comment by Christoph John [ 08/Aug/12 ]

OK, thanks.
Yes, this was fixed for 1.5.2.

Generated at Sat Nov 23 11:04:54 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.