On 2012-09-12, at 2:58 PM, Alexis Tual wrote:
> Hi,
>
> 2012/9/13 John Huss <johnth...@gmail.com>
> >>> The state the app was in when I took that jstack was that no login was
> >>> possible and user's requests would not return, ultimately running into
> >>> "no instance" responses after the timeout elapsed.
> >>
> >> Grep the app logs for OutOfMemory, that is one possibility. They look
> >> ready to accept connections. It could also be that they got so back
> >> logged that wotaskd gave up on them and decided they were dead. Having
> >> the lower numbers above should help in this respect - the app will be able
> >> to recover more quickly.
> >
> > Never out of memory. The app is allowed to grow up to 24 GByte, stays in
> > the 1-4 GByte range in normal use and occasionally grows up to 12 GByte
> > with the most advanced statistics that tend to suck in the whole database.
> >
> > That's also the reason though that I can't use separate EOF stacks for the
> > statistics, because as soon as there were more than one of them, I'd have
> > multiple 10 GByte-ish snapshot caches. The server has 48 GByte and I don't
> > really want to hit that limit... and with separate stacks, it also would be
> > difficult to keep the stats reflect current changes in the other stacks.
>
>
> I am not sure about the background threads (depends on how long OSC locks are
> held), but using ECs sharing the same EOF stack with regular requests is
> likely to cause problems like you are seeing.
>
> Do you mean that the application would be unresponsive while the lock was
> held in the background thread, or that simply doing it that way will lead to
> unrecoverable deadlocks?
> If you do massive fetches in the background, that will block other requests
> as the only OSC is locked.
Correct.
> That said, I think (and correct me if I'm wrong) if you lock the ec but do
> not fetch anything with this ec, other ecs can still access the db.
Also correct. The lock contention is only when fetching or saving. It can
also happen if your code (or Wonder code that you are using) locks something in
EOControl or EOAccess.
> Anyway, the best practice is to use a dedicated OSC to do background work.
> Maik, you should use a dedicated OSC for your stats, and try, if possible to
> clean memory, for example :
>
> ec.lock();
> try {
> // huge loop to compute stats
> for (i = 0; i < 1000000; i++) {
> // doing stuff with ec...
> // cycling the ec
> if (i % 100 == 0) {
> ec.unlock();
> ec.dispose();
> ec = newEditingContextForMyWork();
> ec.lock();
> }
> }
> } finally {
> ec.unlock();
> }
If practical (I recall that it is not in Maik's case) that can be a good way of
limiting memory usage.
Chuck
--
Chuck Hill Senior Consultant / VP Development
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/gvc/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
