Re: Warning: Request will be REDIRECTED to non-refusing instance
Re: Warning: Request will be REDIRECTED to non-refusing instance
- Subject: Re: Warning: Request will be REDIRECTED to non-refusing instance
- From: Daniel Muller <email@hidden>
- Date: Wed, 24 Sep 2003 22:44:20 +0200
Chuck Hill <email@hidden> wrote:
Hi Chuck,
> Is that the first request? If so, you can try increasing the app launch
> time in JavaMonitor (I forget what it is called exactly). Also, if you are
> restarting all 10 apps at once that might be too much. Try doing 5 then
> another 5 an hour later or something like that. This will also prevent
> service outages.
Normally the application is set to use phase startup with 90 sec. between fire. So I will check that carefully.
> >I've changed
> >the minimum sessions to 10 like that wotaskd is able to restart
> >instances every day.
> >
> That will kill ten active users...
Yes, but normally librarians don't work so early... ;-) they have regular habits.
> >> If you can get a thread dump (see the archives here or on Omnigroup)
>
> >> that should show if this is the case.
> >
> >Seems to be used only from Terminal, in my case the application is
> >always working fine during development
> >it's only while running on deployment that this problem happened.
> >
> >Is it possible to get a thread dump of deployed instance?
> >
> Deployed on what? You can do it with a kill signal on UNIX. On Windows,
> there is no way. Another, perhaps better, alternative is it launch the
> apps so that you can connect with a remote debugger. Then you can get all
> the info you need.
Deploy on OS X Server. I tried the "kill -3 {pid}" to dump the threads states
but nothing in my log file. I suppose the stdout is not redirected to a file
or if it's the case I don't know which one! I will investigate more about
this very useful facility.
> >> Are you being careful to lock and unlock all of your editing contexts
>
> >> correctly?
> >
> >Yes I do, but I never lock/unlock the defaultEditingContext.
> >I'm wondering if it's required in some context?
> That is locked for you as long as you only access it between the calls to
> awake() and sleep() in session. You ***do*** need to lock any editing
> contexts *nested* in this one (child ECs).
Well, now it's clear. I thing I only use the defaultEditingContext during
the request/response loop and in the session's terminate. I've added the
lock/unlock in terminate (before super.terminate()) and let see
how it will behave tomorrow.
I don't use nested ECs but I will remember that they have to be
locked/unlocked.
> >BTW, I'm using Oracle database and I can see in the ora trace log that
>
> >there are deadlocks.
> That could also be the problem. Or it might just be a symptom. Perhaps
> the isolation level is set incorrectly?
let see witht the lock/unlock in terminate!
> >EOEditingContext lock/unlock are useful in the same instance but what
> >about between instances, my application have 10 instances.
> >
> You don't need to worry about this.
:-) great!
> >I've a ILLRequestLock table used when I have to lock
> >a ILLRequest row to allow only one writer and many readers.
> >
> Won't EOF's optimistic locking handle this?
Yes but only when the changes are saved. I show another page when the
ILLRequest is locked just to warn the user that he/she can't modify it,
otherwise the first user can edit the ILLRequest until he saves the
changes. It's why I have to unlock the ILLRequests when the session
terminates because sometimes people go to the previous page or just
close the window!
> >Is it required to lock/unlock editing context where all the entities
> >are read-only in EOModeler?
> >
> Yes, unless you have them in teh EOSharedEditingContext.
Why? I load EOs in a normal EC without EOSharedEditingContext,
I never change EOs, they come from another database (using a fetchspec)
and I've set the read only option for all entities in the EO Model
(the model is different for this particular database)
Cheers,
Daniel
--
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.