Re: Scheduled WOApps not scheduled, Barbarian Solution
Re: Scheduled WOApps not scheduled, Barbarian Solution
- Subject: Re: Scheduled WOApps not scheduled, Barbarian Solution
- From: Chuck Hill <email@hidden>
- Date: Fri, 28 Apr 2006 09:32:01 -0700
Hi Wolfram,
On Apr 28, 2006, at 12:55 AM, Wolfram Stebel wrote:
Am 27.04.2006 19:05 Uhr schrieb "Chuck Hill" unter
<email@hidden>:
On Apr 27, 2006, at 12:37 AM, Wolfram Stebel wrote:
Hi List,
i have a WOApp running in 7 instances. Each night i scheduled one
of them to
restart at 3AM.
When i come to the server in the morning, one instance (the
scheduled one)
shows "refuse new session=ON" but there is no new log for the
instance
showing up after restart.
So i suspect that the restart failes, only the refuse is set and
nothing
more.
I think you are probably mis-interpreting what is happening. The
application will not restart until all of the sessions have
terminated (unless you have configured it to restart when there are
some number of remaining sessions). What are you describing is what
happens when sessions get hung / deadlocked. Sessions in this state
are never checked back in and so never terminate. As the sessions
don't terminate, neither does the app. It just sits there in
shutdown mode waiting for the sessions to terminate and they never
will. So the problem is not that your app is not restarting, but
that it is not actually stopping!
I would suggest getting a thread dump from the application when it
is in this state, that should diagnose the problem. In your code,
the first thing to ensure is that the constructor, awake, sleep, and
terminate methods of session can't throw an exception ever.
Chuck
Thanks Chuck and Jerry,
as you wrote (but how could you know? :-) ), there have been a lot
open
sessions in each of the instances.
There has been another "infect" in my application, it always
returned to the
previous page on a browser refresh...
That sounds like your page to page navigation has a defect in it.
The Barbarian solution: I simply restarted the server and
everything seems
to be fine again, also the refresh problem.
But...
You can't do this too often on a production server :-)
As Jerry notes, rebooting is not the best way to handle this. :-)
Is there a simple way to monitor the sessions without coding tons
of lines?
Is there a default set of information one should log in it's
application, in
addition to the logs of the application logic?
I usually log out the sessionID() in the session constructor, awake,
sleep, and terminate. This helps when examining the log and linking
operations together. I also log in the constructor and terminate the
start and end of the life of the session. Finally, in the
constructor and terminate, I log out the number of active sessions at
that point. This, along with a thread dump when the application is
not restarting, are a good place to start the hunt.
As WO development is fairly documented (with Practical
WebObjects :-) ),
deployment and maintenance of WO applications is not. Shure, most
of us are
developers... :-) but shouldn't the applications run somewhere for
profit
too?
Is it worth another book from Chuck and Sacha?
One at a time... :-) And the Apple docs are pretty good on this. I
think we would exhaust anything we could add in a chapter or two.
Chuck
--
Coming in late 2006 - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden