Brilliant! An add-on "finally" statement did get the active session count
down as expected in JavaMonitor. I have read through wiki about the
WOSession and its session lock, but not this bit of information to force it
to terminate. Will update later.
There must be somewhere seriously locking the session. As of now, all
worked fine except the last statement after the call to super.terminate()
will never executed, e.g. NSLog statement for activeSessionCount(). I am
not quite sure why it is unable to terminate, could it due to eo in
wocomponent. And just checked my code that no WOSession has been declared
in any wocomponent.
At the point of sending my previous email, I had not yet received the email
about try-finally suggestion. So apology if any ignorance and thanks...
Cheers
Cheong Hee
----- Original Message -----
From: "Chuck Hill" <email@hidden>
To: "Cheong Hee (Gmail)" <email@hidden>
Cc: <email@hidden>
Sent: Saturday, July 18, 2009 1:27 AM
Subject: Re: Inaccurate active session count in JavaMonitor
On Jul 17, 2009, at 10:15 AM, Cheong Hee (Gmail) wrote:
Adding the code as mentioned earlier, I have run three sessions with the
following conditions:
session1: log out gracefully by the user
session2: time out occurs
session3: time out occurs
The sequence of sessions are session1, following by session2 and then
session3.
When session1 is terminated by the user, the log shows
session.terminate() is called and the active session count is reduced by
1. So the total active session count = 2.
When session2 is time out, the log also shows that session.terminate() is
called. However the active session count does not reduce, and keep the
count = 2.
The session3 is the last session being time out. The log again shows
that session.terminate() is called, however the active session count = 2.
The only difference is when timeout, session.terminate() is invoked by
Session Timeout Thread whereas the normal log out session.terminate() is
callled by WorkerThread.
JavaMonitor also showed the active count = 2. And the count will be
there forever until the next stop-start sequence of instance.
Any idea to solve this or reduce the count somewhere by coding when
timeout happens?
Something is very wrong with your application. I can't guess what it
is. Did you add the try...finally to terminate like I suggested? If
not, that is the first thing to so.
