10-25-2023, 02:53 PM
We have an IntraWeb ISAPI application that runs during the day, with an average of 300 concurrent IW sessions. CPU usage is between 10 and 30% all the time.
We use Delphi 11.3 with IntraWeb 15.2.69 (we also use 15.4.2, but not yet for production work).
However, sometimes, the session manager seems to "die" when terminating a session. We get an Access Violation, and as of that moment, new sessions will be created, but old ones (and new ones) will never be freed and removed again. As a consequence, the session count increases (we've seen 1000 concurrent sessions, with still "only" about 300 really active), and the memory usage increases as well, since these sessions are no longer destroyed.
When we detect this situation, we often need to restart the application to solve the problem, although it will remain fully functional (until all memory of the server has been used, but this gives us a few hours to respond).
In other situations, even less frequent, the session manager seems to be unable to create new sessions. Connections are made, but no new sessions and no main forms are generated. The session count does not go up.
In both cases, the average CPU usage drops from the minimum of 10% CPU to about 0% CPU. I have a feeling this means that the "overhead" for the session manager is gone, and this helps in my thought that the session manager may be broken at those times.
Question: is there any way to inspect / query / interrogate the IntraWeb session manager to see if it's still alive? Restarting may be a problem as I do not want to kill the sessions that are still in active use (although the second case often leads to an IIS "Ping" reset, as the application pool itself may not respond to a ping within 90 seconds).
I also wonder if anybody else is seeing this behavior, or if we are just unlucky. I may very well be our application that upsets the session manager, but I wonder who and how.
Thanks in advance for any pointers, tips or hints.
Groetjes, Bob Swart
We use Delphi 11.3 with IntraWeb 15.2.69 (we also use 15.4.2, but not yet for production work).
However, sometimes, the session manager seems to "die" when terminating a session. We get an Access Violation, and as of that moment, new sessions will be created, but old ones (and new ones) will never be freed and removed again. As a consequence, the session count increases (we've seen 1000 concurrent sessions, with still "only" about 300 really active), and the memory usage increases as well, since these sessions are no longer destroyed.
When we detect this situation, we often need to restart the application to solve the problem, although it will remain fully functional (until all memory of the server has been used, but this gives us a few hours to respond).
In other situations, even less frequent, the session manager seems to be unable to create new sessions. Connections are made, but no new sessions and no main forms are generated. The session count does not go up.
In both cases, the average CPU usage drops from the minimum of 10% CPU to about 0% CPU. I have a feeling this means that the "overhead" for the session manager is gone, and this helps in my thought that the session manager may be broken at those times.
Question: is there any way to inspect / query / interrogate the IntraWeb session manager to see if it's still alive? Restarting may be a problem as I do not want to kill the sessions that are still in active use (although the second case often leads to an IIS "Ping" reset, as the application pool itself may not respond to a ping within 90 seconds).
I also wonder if anybody else is seeing this behavior, or if we are just unlucky. I may very well be our application that upsets the session manager, but I wonder who and how.
Thanks in advance for any pointers, tips or hints.
Groetjes, Bob Swart