Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
session timeout thread
#1
IntraWeb 15.5.x has made a significant positive change by introducing the TSentinelThread in the ServerController, to watch the internal workings of the session timeout thread activity, and the sentinel thread will restart it when needed. Although there is no way to know for sure (there is no message or output that the TSentinalThread has actually restarted the session timeout thread), we have not encountered situations where sessions were no longer destroyed.

Except... for a relative new situation, where one thread is using 25% CPU (we have 4 -core servers), and it looks like this may be the session timeout thread, since new session can still be created, but older sessions are no longer destroyed. And after a few hours, this leads to hundreds of extra sessions and memory overhead.

Could it be that the session timeout thread is locking some resource, and waiting for another reasons to become available? In other words, could this be a deadlock situation?

The next time this happens, I will attempt to kill the thread that takes 25% CPU. If this is indeed the session timeout thread, then hopefully the sentinel thread will restart it (although this will leave the locked resources probably still locked, so there's a big chance we'll end up in the same deadlock situation again.

If you have anything that could help us pinpoint or resolve this problem, we would be very grateful. Thanks.

Groetjes, Bob Swart
Reply
#2
Hi Bob,

Yes, I have already considered that the sentinel thread should log whatever situation that requires it to restart the timeout thread... it's in our todo list.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)