here's my problem. I have a web app that's deployed on a tomcat cluster. i have a requirement in the application, that the admin can kill some user sessions when he wishes. for that we need the session details of all the users which we can save it in the application. now, the problem is that, how do we know which session is attached with which tomcat instance of the cluster?
is there a way, where we can get this information or , can we send information to the proxy server, etc. to kill the required user session ?
please help. any other suggestions are also welcome.
1. Resort to clustering, so that sessions are cluster-wide - then you can kill sessions on any server, and it will get replicated everywhere.
2. Store Session and Server information in database (i.e when it is created.). When a session is being created you know on what server it is happening (give every server a unique name), so you can easily store this information in a database table.
Not knowing exactly what that code is doing, you may get lucky.
But in general if the code has put itself into a perpetual loop, you screwed
and the machines power switch works... no just kidding, you'll have to
restart TC ;)
If that code is talking to a mail server, or some other server... then you
maybe able to knock it out of its coma, by just restarting that server...
assuming thats not worse than restarting TC.
Sometimes its because something like javamail used directly in the code is
stuck and cant find its server...
Its noramlly always an indication that the code needs more error checking
and a better failure mode.
If its just one stuck thread... dont think there is too much harm in just
leaving it... but if the threads are building, ie every request to that
webapp is now getting stuck... then you have to restart TC after undeploying
that webapp, unfortunately... I think it will need a rewrite...
Just wondering if its really stuck... I think eyeball the processor usage as
I still use sockets the old way... ie TC's standard blocking socket stuff,
but there have being posts here... think its called NIO or something which
basically allow the developer to really control that socket async.
I imagine that with keep alives that it could well look like a thread is
stuck... and it may be a really fancy app just keeping everything open...
just wondering because if the software was screwed one would expect (I
think) to see the thread count increasing.... not just one thread
working.... I think...
You got me wondering if its possible to make that happen with the new TC
socket stuff.... ie its normal ;)
So, I didntreally help at all..... ha ha