Erik Remmelzwaal <jhf.remmelzwaal@...> writes: > > > When you google on 'apache ApplicationHttpRequest getAttribute looping stack overflow' you will find a number of comparable reported issue. I think the following might be interesting to check: https://issues.apache.org/bugzilla/show_bug.cgi?id=47017 I would also advice to post the 'bottom' of the stack trace; before it started looping. Inform when the issue occures, did you try to deploy your application on other environment. Did it occurred after a certain change in your program etc.Erik > 2012/1/23 Cliff Jones <cjo...@avidity.biz> > 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 ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users