By focusing on the massive disconnection, now I see that it is preceded by an abnormal Garbage Collection activity.
Until then, the JVM seems to have plenty of memory and it seems to recollect the consumed memory very easily.
However, at 13:02:30, even though the free memory is huge, it probably initiates a major collection and this keeps the Server blocked for about 20 seconds.
The block in the data flow eventually causes almost all the active sessions to be interrupted and restarted
(this is the expected consequence, because of the checks in the client SDK libraries).

This kind of accidents can and should be avoided by acting on the JVM configuration, which is specified in the Server's launch script, LS.sh or LS.bat.
Please check the GC parameters used. Try specifying an explicit maximum pause requirement through the -XX:MaxGCPauseMillis setting; the reconnections are triggered by pauses longer than a few seconds, so you don't have to force a tight requirement.

Can this episode explain the problems observed in your tool?
I see that the disconnections are then recovered successfully with new sessions and new subscriptions. Which client SDK is your tool based on?
Did you notice permanent damages in your tool's behavior?