Cool. Sounds even better. Prolly need to separate (in ExpirationMonitor)
if (session.isDone() || age maxLoginDurationMillis) {
list.add(session); // to unregister
session.setDone(true);
it.remove();
}
into
if (session.isDone()) {
list.add(session);
We had the same issue, and didn't see much about it online (except this note
and bug GERONIMO-2100)
I debugged through the Geronimo code for a while today, and I think I've
found the solution (which I also think is the proper solution to
GERONIMO-2100 as well...)
The problem
[In this
Sorry -- forgot the code...
Replace
assert context != null : No registered context;
with
if (context == null)
throw new AccessControlException(No registered context (may have
expired));
Scott Stanchfield wrote:
Suggested Fix
Change getCurrentContext() to throw and
I wonder if it would be appropriate to replace the expired context
with something representing the no one identity? then the ACE
might occur naturally when no one can't do something but stuff that
is actually allowed for an unauthenticated user would still work...
so I think this would
We are using geronimo-1.1.1 and have a reproducible problem.
When we start Geronimo with our apps deployed in it, and leave it to
run for two days, we cannot then access geronimo for some requests.
When we submit a simple request, e.g., http://localhost:8080/console
we get the error shown at the
On Jul 31, 2007, at 10:30 AM, Geronimo User wrote:
We are using geronimo-1.1.1 and have a reproducible problem.
When we start Geronimo with our apps deployed in it, and leave it to
run for two days, we cannot then access geronimo for some requests.
When we submit a simple request, e.g.,
On 7/31/07, Kevan Miller [EMAIL PROTECTED] wrote:
So, all is well for the first two days?
Yes, no issues seen in the geronimo.log.
Then some requests fail (e.g.
the console), but others work? No other indications of problems in
the server log?
I'm working on the hypothesis that requests
