Skip to Content
Last modified by David Avendasora on 2010/11/30 06:34
From version 3.1
edited by Pascal Robert
on 2010/09/13 00:12
Change comment: There is no comment for this version
To version 1.1
edited by smmccraw
on 2007/07/08 09:45
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Deployment-Scheduled Restart
1 +Programming__WebObjects-Web Applications-Deployment-Scheduled Restart
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.probert
1 +XWiki.smmccraw
Content
... ... @@ -1,6 +1,6 @@
1 -== Scheduled Restart Fails ==
1 +== Scheduled Restart Fails ==
2 2  
3 -=== Chuck Hill ===
3 +=== Chuck Hill ===
4 4  
5 5  Let's take a look at what happens in a little more depth. When the appointed time comes, wotaskd sends the application a message to start refusing new sessions. The application will start redirecting all subsequent requests without a session to an instance that is not refusing new sessions. Of course, in your case eventually all are refusing and the woadaptor throws up its hands in dismay and declares "No Instance Available".
6 6  
... ... @@ -13,7 +13,7 @@
13 13  Stuck threads usually result from some sort of thread deadlock and can often result from immortal sessions when a request is made for a session that was never checked in from another thread. A similar situation can occur if your are creating threads in your application that are not marked as daemon threads and not shut down when the application terminates.
14 14  
15 15  OK, all that is well and good but what do you do about this? The first thing you want is to wait for this to happen and get a thread dump of the application. There are some instructions here:
16 -[[http://lists.apple.com/archives/webobjects-dev/2003/Sep/msg00362.html]]
16 +http:~/~/lists.apple.com/archives/webobjects-dev/2003/Sep/msg00362.html
17 17  Note that the file you need to edit is in /System/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/Resources. Make sure that the appserver user has write permissions on the directory/file you point it to.
18 18  
19 19  The next thing you want to do is to add some better logging to your application. At a minimum, I would suggest:
... ... @@ -25,8 +25,10 @@
25 25  * Log when session are refused and activeSessionsCount() in refuseNewSessions(boolean)
26 26  * Log when application's terminate() is called
27 27  
28 -== Sending Notifications on Failed Restart ==
28 +== Sending Notifications on Failed Restart ==
29 29  
30 -=== Chuck Hill ===
30 +=== Chuck Hill ===
31 31  
32 32  My first choice would be to fix your code. Second, it you have a long session time out and users are still working, then it could take quite a while for the app to restart (as long as the users keep working plus the session timeout). Third, if the JVM is waiting on a stuck thread there is not much you can do as any daemon thread to send the text page would have been killed already (hmmm, I think so at least). OK, so ignoring all that, start a timer as a daemon thread in refuseNewSessions(boolean) when true is passed. When the timer fires, send the text message. Or, if you like to sleep as much as I do, just call System.runtime().exit(1). If refuseNewSessions(boolean) is later called with false, kill the timer. That is just in case someone is clicking around in JavaMonitor.
33 +
34 +Category:WebObjects