Verifies the integrety of the projects, as builds are executed immediately after a code change was detected. This plan provides no artifiacts (use a nightly build instead).

Build: #2230 was successful Changes by daryl herzmann <akrherz@iastate.edu> and Guus der Kinderen

Build result summary

Details

Completed
Queue duration
10 seconds
Duration
2 minutes
Labels
None
Agent
Default Agent
Revision
e6dcdb364c84f7a321cea3cb7c71ecd1ea6b7964
Total tests
472
Successful since
#2137 ()

Tests

Code commits

Author Commit Message Commit date
daryl herzmann <akrherz@iastate.edu> daryl herzmann <akrherz@iastate.edu> e6dcdb364c84f7a321cea3cb7c71ecd1ea6b7964 Merge pull request #1977 from guusdk/OF-2367_TCP-clients-unable-to-connect
OF-2367: TCP clients unable to connect
Guus der Kinderen Guus der Kinderen 5f8729055a5698d8ae57836144ecb2a34a71e01a OF-2367: Catch all Throwables in IoHandler# implementations
Prior to this change, an Error would bubble up into MINA's OrderedThreadPoolExecutor's Worker, where it would cause the worker thread to be closed, without the count of available (idle) worker threads reflecting this. This in turn prevents MINA from creating new worker threads (as it thinks it has idle threads), effectively starving. See DIRMINA-1156.
Guus der Kinderen Guus der Kinderen 88d3161c69de9609f495c933b2969f61e45f3db4 for OF-2367: Do not retain reference to Session for a long time
When a client session has finished resource binding, Openfire will send a version query after some delay.

This commit prevents a reference to the Session object to be retained while waiting for that delay to pass. Instead, the session address is stored, and used to re-obtain the session after the delay has expired.

There is (unproven) concern that retaining a reference to the session instance is a factor of OF-2367. With this commit, this no longer is a concern.
Guus der Kinderen Guus der Kinderen 5385c7d86a4c9b2062cdec2e88fe5fdae6c59364 for OF-2367: Log exception when manual session close fails
When an admin attempts to close a session and this fails, the resulting exception should be logged.

Ignoring exceptions assumes that a certain condition is present, which might not be the case. Without the exception being logged, there is no way to find out. Exceptions should always be logged - even if they're expected.

Jira issues

IssueDescriptionStatus
Unknown Issue TypeDIRMINA-1156Could not obtain issue details from Jira
Unknown Issue TypeOF-2367Could not obtain issue details from Jira