> > I have a StackOverflowError using Stripes on JBoss EAP 5.1. The OS is REL,
> and
> > using Sun (Oracle) Java 1.6. Has anyone else seen this issue or maybe have
an
> > idea where to start?
> > ----------
2012-01-23 13:50:15,060 ERROR
> [org.apache.catalina.core.ContainerBase.
> > [jboss.web].[localhost].[/].[StripesDispatcher]] (ajp-xxx.xxx.221.212-8009-
1)
> > Servlet.service() for servlet StripesDispatcher threw exception
> > java.lang.StackOverflowError
> > at
> > org.apache.catalina.core.ApplicationHttpRequest.getAttribute
> > (ApplicationHttpReques
> > t.java:220)
> > at
> > org.apache.catalina.core.ApplicationHttpRequest.getAttribute
> > (ApplicationHttpReques
> > t.java:222)
> > at
> > org.apache.catalina.core.ApplicationHttpRequest.getAttribute
> > (ApplicationHttpReques
> > t.java:222)
> > --------
> > That last line is repeated about 1000 times in each stack trace.
> > Let me know what information that I could provide which would be helpful in
> > tracking this down.
>
> Yes, I had found that too. Unfortunately the log only contains about 20,000
> lines when the app server crashes, and the "beginning" of the request is never
> displayed. This is after the admin increased the size of the stack to about
10K
> on the advice of RedHat. This was to sidestep the bug in Sun's JVM where it
> does not calculate a StackOverflowError correctly and results in "Segmentation
> fault" with *no* logging done.
>
> I find it particularly interesting the comment (in the link you provided) from
> Mark Thomas that "it looks like either an application issue or a framework
> issue."
>
> I have verified that the application itself does no request wrapping. Since
the
> app server (JBoss) is built on Tomcat I'm afraid that leaves a prime suspect:
> Stripes. However, I don't have enough information to declare that I have a
> smoking gun. We were supposed to go to production this week using the Stripes
> framework for the first time but now that is on hold until we can get this
> resolved.
>
> Here is what we did get from the Apache log:
>
> 10.214.116.44|10.214.116.34.1327423461486961|[24/Jan/2012:10:45:12
> -0600]|/UserLogin.action||200|5072|534225|HTTP/1.1|GET|-|
http://ireports-
>
jboss.corp.sprint.com/|Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101
> Firefox/9.0.1
>
> So far this behavior has only been observed when Firefox is used. It also
turns
> out (and I think this could really be significant) this occurs at the end of
> NTLMAUTH challenge/response sequence. Remember, this occurs all within one
> connection, using multiple HTTP requests. Is it possible Stripes is
"wrapping"
> the request object the first time in, then "re-wrapping" it the second request
> (this time a Stripes request wrapper) with itself? Perhaps the original
request
> is re-used by the container, and Stripes doesn't check for this condition.
>
> I know this will be rare in the "outside" world, but this is a corporate AD
> domain-based intranet environment. The project is high profile compensation-
> related application.
>
> I'm just hypothesizing at this point, but hopefully someone on this list will
> recognize something and help me get out of this pickle.
>
> Thanks,
> -Cliff
>
RSS Feed