I think it would be way better to not ever touch EOs in terminate() (No logging of EOs, either!).

I had some deadlocks from exactly this, presumably because it's also called from _terminateByTimeOut() and _terminateByJ2EE(), which don't have the default EC locked (a bug, please report this...).

Cheers, Anjo



Am 16.07.2009 um 14:51 schrieb Jean-Francois Veillette:

There is a potential problem if logOnUser is an eo registered in an editingContexte that is unlock() earlier in the method.
What you could do is :
public void terminate() {
        String audit = null;
        if (logOnUser != null)
                audit = "User " + logOnUser.vName() + " is logging out.";
        lockManager().unlock();
        _multiECLockManager = null;
        //RSP07042006
        if (logOnUser != null)
                this.auditLogWithType(audit, AuditHistory.OTHERS_TYPE);
        super.terminate();
}

Le 09-07-16 à 05:35, Cheong Hee (Gmail) a écrit :

I just confirmed and checked my code that session.terminate() has overriden as the following:
/**
 * unlock ec when terminates.
 */
public void terminate() {
    lockManager().unlock();
    _multiECLockManager = null;
    //RSP07042006
    if (logOnUser != null)
this.auditLogWithType("User " + logOnUser.vName() + " is logging out.", AuditHistory.OTHERS_TYPE);
    super.terminate();
}

I will need to confirm if the application.activeSessionCount() printout against JavaMonitor and see if the count is tally upon session time out. My current timeout has set to -WOSessionTimeOut as 90. In fact, when I did a proper log out, the count is reduced in JavaMonitor. Thanks all and will try it out with code given.

----- Original Message ----- From: "Mark Ritchie" <mark.ritc...@mac.com >
To: "Chuck Hill" <ch...@global-village.net>
Cc: "Cheong Hee (Gmail)" <chn...@gmail.com>; <webobjects-deploy@lists.apple.com >
Sent: Thursday, July 16, 2009 4:56 PM
Subject: Re: Inaccurate active session count in JavaMonitor


On 15-Jul-09, at 9:21 AM, Chuck Hill wrote:
The memory usage stats are meaningless, but the active session count has been accurate in my experience. I suspect that your code has bugs in it that are preventing session termination. Get a thread dump and see if you have deadlocked threads.

This is my experience as well. The count of currently active sessions is pretty important to management of deployed applications. Perhaps you've overridden session.terminate() and forgotten to call super.terminate()? Or perhaps, as Chuck so wisely points out, it's some other problem with your code.

Personally, I would use jdb to intercept what's happening when a session terminates.
Alternatively, you could add code like this to your Session.java:

public void terminate() {
// dump a backtrace when the session is terminated
RuntimeException e = new RuntimeException();
e.printStackTrace();

// show the before and after count of the active session count from WOApplication NSLog.debug.appendln("before activeSessionCount = " + WOApplication.application().activeSessionsCount());
super.terminate();
NSLog.debug.appendln("after activeSessionCount = " + WOApplication.application().activeSessionsCount());
}

OTOH, it could be some weirdness with your installation...
Try building and deploying a new project with the terminate code above and launch it with -DWOSessionTimeOut=5 Then connect to the instance, see the home page, then wait and watch to see if the session times out.

Good Luck!
Mark

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com )
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/jfveillette%40videotron.ca

This email sent to jfveille...@videotron.ca

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects- dep...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/anjo%40krank.net

This email sent to a...@krank.net

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list      (Webobjects-deploy@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to