Currently when the OOM happens, the functioning of the server would most likely be severely impacted (i.e. it won't be working properly in one way or another). What's more, usually ConnectionManagers would not be impacted in the sense they would still be listening on the ports (and accepting simple network connections), thus external monitoring tools may be unaware that something is off.
One solution would be to configure JVM with -XX:OnOutOfMemoryError option that would kill the process thus forcing the restart, but that conflicts with -XX:+HeapDumpOnOutOfMemoryError option, which is quite useful for the purpose of troubleshooting.
Alternatively try {} catch (OutOfMemoryError oome) { TigaseRuntime.getTigaseRuntime().shutdownTigase(…) } could be used with delayed shutdown and OOME re-thrown.
wojciech.kapcia@tigase.netbatch edited6 months ago
Currently when the OOM happens, the functioning of the server would most likely be severely impacted (i.e. it won't be working properly in one way or another). What's more, usually ConnectionManagers would not be impacted in the sense they would still be listening on the ports (and accepting simple network connections), thus external monitoring tools may be unaware that something is off.
One solution would be to configure JVM with
-XX:OnOutOfMemoryError
option that would kill the process thus forcing the restart, but that conflicts with-XX:+HeapDumpOnOutOfMemoryError
option, which is quite useful for the purpose of troubleshooting.Alternatively
try {} catch (OutOfMemoryError oome) { TigaseRuntime.getTigaseRuntime().shutdownTigase(…) }
could be used with delayed shutdown and OOME re-thrown.