InBandBytestreamManager followed an unusual pattern: Within the
connectionTermianted() callback, it would remove itself from the
'managers' map. This allowed for multiple instances of an
InBandBytestreamManager to exist for the same connection, causing all
kinds of issues.
This fixes the issue by changing InBandBytestreamManager to use the
Smack-idiomatic pattern used by managers.
We also do no longer reset the listeners if the connection is
termianted, as listeners (and handlers) typically persist until they
are explicitly removed by the user.
As positive side-effect, the number of indeterministic unit-tests,
caused by using Thread.sleep(), is reduced. The executor service in
InitiationListener was also removed, because the IQ handler is already
called asynchronously to the connections main loop.
Thanks to Anno van Vliet for reporting this.
The current code would work just fine for a connection having
multiple endpoints. However, when there is only one endpoint
ConnectionAttemptState.nextAddress() would return null, since
connectionEndpointIterator has already iterated over the only
possible value in the contructor leading to a NullPointerException.
This means that during establishment of a connection having multiple
endpoints, the first value inside connectionEndpointIterator would
always be overlooked.
To ensure the thread starting the reader/writer threads sees them
running and eventually waits until the 'running' boolean is reset to
'false' upon connection termination.
Since the current variant of notifyConnectionError() does not execute
most of its work in a new thread, especially since instantShutdown()
is called in the invoking thread, we have to mark the connections
reader or writer threads as no longer running prior them invoking
notifyConnectionError(). Otherwise they will end up waiting for
themselves to terminate.
To make it clear that this will either return if the condition is
true *or* if a connection exception happened.
Also introduce waitFor(), which is deliberately not named
waitForCondition() because it carries a different semantic.
SMACK-888 has a mention of unreachable code and is now solved
under commit 0f7b7df.
This integration test tests those class entities which were to
be set by previously stated unreachable code.
