So this turns out to be a little less straightforward and easy to fix than i hoped.
For SendingTime Accuracy problems, the workflow is this (demonstrated by putting a breakpoint in Session.doBadTime or Session.generateReject

Login comes in for a new session
bad time (sending time sync problem) is detected and generateReject is called
since we never received a valid logon for this session, generateReject throws an exception and as a result we never send the reject or logout (which could have the text message)

The connecting session is simply dropped (disconnected) - with no logouts sent.
All you see on the client side is a session disconnect

Not sure what the best way to approach this problem is. Ideally, we'd just catch the exception and send a logout (or always send a reject even if it's not logged on).

Or maybe catch the exception in Session.doBadTime(), send a logout (with error messages as logout text) and rethrow the exception to force a disconnect?
I've modified the code and acceptance tests to check for that, and it seems to work.

Steve, what are your thoughts?

I also wanted to send out a useful reject message for the case when you have multiple connections for the same session.
The current behaviour is to just close the session when multiple connections are detected - see AbstractIoHandler.processMessage().

I'd imagine the right behaviour is to keep existing session, and to send a reject/logout message to the 2nd connection

Fixing this is a bit more non-trivial - it'll require some fairly invasive changes to allow certain methods in Session to be public if we wanted to reuse code.
What's the right behaviour? Create a new "logout" session that only sends a logout/reject out, and then close it immediately?
What would be the best way to implement that?

Sending a text reason for forced logout/disconnect added in rev 870 .

Still need to figure out the best way to approach sending a rejection message on disconnect when you have multiple simultaneous connection attempts.

wrong link to the rev above. the right rev is here

I've created a tag for the QFJ-342 fix that deals with notifying on "multiple connections from same senderCompID" case.

http://quickfixj.svn.sourceforge.net/viewvc/quickfixj/branches/qfj-342/core/

The fix works fine with Executor/Banzai examples. I've written an acceptance test for it which passes as well, but somehow my fix really messes up some of the subsequent acceptance tests. And I'm not sure if it's due to the way acceptance tests are setup, or if there's a lingering error or a false assumption in the way that i have fixed code to send a reject.

I removed all acceptance tests but 2 in the branch - one that exercises QFJ-342, and another that fails subsequently. If you remove the 1b_DuplicateIdentity.def test then all the others pass as well

Not sure where to go from here - would like to speak with someone that knows more about the acceptance test suite to see what may be going on.

Acceptance tests
AcceptorIOHandler change

Resolved based on Toli's comments.