geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Stanchfield <scott.stanchfi...@hcrest.com>
Subject Re: Asking again: No registered context in security getCurrentContext() after apps run for two days.
Date Wed, 10 Oct 2007 22:43:25 GMT

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 description, getCurrentContext() refers to 
org.apache.geronimo.security.ContextManager.getCurrentContext() ]

The JaasLoginService.ExpirationMonitor kills contexts based on a maximum
login time (the default is one day). To see if this initiating the problem,
I changed the timeout to two minutes. The problem appeared, though not on
every access.

I debugged and watched what was happening thread-wise. It seemed that once a
thread went bad, all requests handled in that thread die with the
NullPointerException (or if assertions are on, the AssertionError.)

The exception is thrown from getCurrentContext() because it is being asked
for a context that has been unregistered by ExpirationMonitor.

There are some BeforeAfter processing that take place around calls to
getCurrentContext(). In particular,
org.apache.geronimo.tomcat.interceptor.PolicyContextBeforeAfter calls
ContextManager's setCallers() and popCallers() methods.

When getCurrentContext() throws a NullPointerException, the "after"
processing is skipped; this fails to call popCallers(). This is very evil
indeed, as the current thread is left in a bad state, thinking it already
has a subject, which has recently been invalidated by the ExpirationMonitor.

Any further HTTP requests assigned to that thread are now treated as though
they have a Subject, which in turn causes a NullPointerException from this
method.


Suggested Fix

Change getCurrentContext() to throw and AccessControlException when context
is null to prevent skipping of "after" processing in BeforeAfterValve. All
callers of getCurrentContext() already catch AccessControlException and
treat it as "not authorized".

I haven't tried this yet (I'm settting up the sources for a build), but I've
got warm fuzzies about it...

Thoughts?
-- Scott


Geronimo User wrote:
> 
> [...]
> 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.
> 
> [...]
> 
> 2007-07-30 09:31:33,415 ERROR [CoyoteAdapter] An exception or error
> occurred in the container during the request processing
> java.lang.AssertionError: No registered context
>        at
> org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:165)
> [...]
> 

-- 
View this message in context: http://www.nabble.com/Asking-again%3A-No-registered-context-in-security-getCurrentContext%28%29-after-apps-run-for-two-days.-tf4193578s134.html#a13146261
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.


Mime
View raw message