If I can add another hint to the thing: if I put
WOAllowsConcurrentRequestHandling to false, the problem seems less
frequent so it's definitely a deadlocking issue. I'm only using
ERXEC.newEditingContext() to create ECs, some are created in
DirectActions, some in Application and of course there's
From what I see some instances don't log the DB Connection error and
still have immortal sessions.
The main problems with immortal sessions is that eventually they end
up with a memory problem, I recall there is a way to make the instance
restart if memory errors happen but I can't remember how.
Regarding the deployment environment (which is not under my control,
as I said before) There are 6 boxes:
2 webservers (one each for 2 different apps)
2 WO nodes with wonder's latest wotaskd
1 Mysql DB
1 JavaMonitor box
I noticed that the box that runs JavaMonitor doesn't have wotaskd
running, is
Sent from my iPhone
On 30/gen/2013, at 17:59, Matteo Centro woli...@matteocentro.it wrote:
Regarding the deployment environment (which is not under my control,
as I said before) There are 6 boxes:
2 webservers (one each for 2 different apps)
2 WO nodes with wonder's latest wotaskd
1 Mysql
Unfortunately I don't have full control of the deployment
environment... It looks like at some times the DB stops responding
with no apparent reason.
Could a simple DB Connection glitch cause a EOObjectStoreCoordinator lock?
Maybe I can tweak the connection dictionary to enable auto reconnect.
Sure, here it is:
Hi Chuck,
I'm posting just to you, I can't have google to index this...
anyway, here is the stack trace:
java.lang.IllegalMonitorStateException
at
java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:127)
at
It's a mess... There are ECs created in some DirectActions, and ECs
created in methods in Application but all the edit operations happen
in the Session EC. All ECs are ERXECs and no explicit locks happen.
Should I explicitly lock the session EC in the terminate method?
Matteo
On Sun, Jan 13,
Sorry to resuscitate such an old discussion but I'm having the exact
same issue...
It's an old application that we inherited, we wonderized it as much
as it's possible but something weird happens in production, sessions
on some instances simply won't die.
Some instances go out of memory and they
have you done tests like sending a backtrace to the session just to see if it
is hung somewhere?
I recall finding sessions getting stuck on a poorly written ec threading issue
that only came up once in a blue moon it seemed.
once I saw a backtrace, it was quite obvious where the trouble was.
stick this in your session constructor, it will log out whenever a
session is created. then you can start figuring out where you are
creating a session outside the RR loop which is the normal culprit...
StringWriter stringWriter = new StringWriter();
Thanks, I'll try that.
Anyway (I can't say it's that but this happens often in instances with
immortal sessions):
I get this in my terminate() method
java.lang.IllegalMonitorStateException
at
java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:127)
at
Hi All -
Wondering if someone can throw me some ideas on solving what looks
like an immortal session problem.
- Start up 1 instance in java monitor.
- User lands on sessionless login page. No sessions.
- User logs in. 1 session.
- User logs out. 0 sessions.
- User logs in. 1 session.
- User
On 20.08.08 10:54, Simon McLean [EMAIL PROTECTED] wrote:
So what could be going on ?
Deadlocks somewhere?
Something appears to be creating immortal
sessions, but forced session termination (by the user logging out) and
session expiration seem to be behaving themselves.
Can you get a
Put a log message (use log.error and smtp appender if you want instant
emails) in the Session constructor and log the stack trace aswell as
any other WOContext/WORequest information to get clues as to what and
when this is going on.
HTH, Kieran
On Aug 20, 2008, at 12:54 PM, Simon McLean
So what could be going on ?
Deadlocks somewhere?
Something appears to be creating immortal
sessions, but forced session termination (by the user logging out)
and
session expiration seem to be behaving themselves.
Can you get a stacktrace of the app? We had things like that with a
not that this solves the problem. can you schedule the session to
gracefully restart?
./me
On Aug 20, 2008, at 1:06 PM, Kieran Kelleher wrote:
Put a log message (use log.error and smtp appender if you want
instant emails) in the Session constructor and log the stack trace
aswell as
On 20.08.08 11:24, james o [EMAIL PROTECTED] wrote:
not that this solves the problem. can you schedule the session to
gracefully restart?
In this case that normally doesn't solve the problem.
The situation he is seeing does normally mean, that sessions are not
terminated properly when
On 20.08.08 11:16, Simon McLean [EMAIL PROTECTED] wrote:
If this was happening what would the user see ? Would the app just
behave like the session was dead and send them back to the login page ?
Normally they would see a not responding application in that case, but would
be able to log in
On Aug 20, 2008, at 10:16 AM, Simon McLean wrote:
So what could be going on ?
Deadlocks somewhere?
Something appears to be creating immortal
sessions, but forced session termination (by the user logging out)
and
session expiration seem to be behaving themselves.
Can you get a
On Aug 20, 2008, at 9:54 AM, Simon McLean wrote:
Hi All -
Wondering if someone can throw me some ideas on solving what looks
like an immortal session problem.
- Start up 1 instance in java monitor.
- User lands on sessionless login page. No sessions.
- User logs in. 1 session.
- User logs
We have a couple of sessionless apps that have started showing this
problem with sessions that don't terminate. It turned out the
sessions were being created by malformed urls coming from malicious
robot web crawlers. The urls were of the form
I had something similar with sessions going bonkers on a public WO
page that our internal google search engine completely trashed. In the
end, robots.txt and explicit rules to deny certain patterns were added
to prevent this.
On Wed, Aug 20, 2008 at 8:17 PM, D Tim Cummings [EMAIL PROTECTED]
22 matches
Mail list logo
