Cliff Jones | 23 Jan 23:10 2012

StackOverflowError on JBoss EAP 5.1

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.  

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
(Continue reading)

Erik Remmelzwaal | 24 Jan 10:19 2012
Picon

Re: StackOverflowError on JBoss EAP 5.1

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 <cjones-539LkxgYNgKpwFb5G8XvHQ@public.gmane.org>
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.


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
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-dev2
_______________________________________________
Stripes-users mailing list
Stripes-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/stripes-users
Cliff Jones | 24 Jan 22:07 2012

Re: StackOverflowError on JBoss EAP 5.1

Erik Remmelzwaal <jhf.remmelzwaal <at> ...> 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 <cjones <at> 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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Cliff Jones | 24 Jan 22:59 2012

Re: StackOverflowError on JBoss EAP 5.1

Cliff Jones <cjones <at> ...> writes:

> 
> Erik Remmelzwaal <jhf.remmelzwaal <at> ...> 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 <cjones <at> 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
> 

Here is another piece of the puzzle.  It appears the event is happening inside 
of the StripesDispatcher servlet:

2012-01-23 13:50:03,714 ERROR [org.apache.catalina.core.ContainerBase.
[jboss.web].[localhost].[/].[StripesDispatcher]] (ajp-144.226.221.212-8009-1) 
Servlet.service() for servlet StripesDispatcher threw exception
java.lang.StackOverflowError
	at 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:220)
	at 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
	at 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
	at 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
	at 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
	at 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
	at 

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Ben Gunter | 25 Jan 14:40 2012

Re: StackOverflowError on JBoss EAP 5.1

This does look vaguely familiar to me, but I don't recall when or where it happened or how I fixed or worked around it. How's that for some valuable insight? ;)


The stack trace indicates this is happening completely within Tomcat. Though it could be Stripes that somehow triggers the behavior, it would be tough to call it a "Stripes problem." Looking at line 222 of the source code for ApplicationHttpRequest here ...



It would be very helpful if you could let us know what's going on in your app and/or in Stripes before this infinite recursion starts. Even more helpful, if you know how to reproduce the problem, would be to put together a small test app to demonstrate it. I won't be available to help for the next several days, but there might be someone on the list who would find this interesting enough to tackle with a little direction.

Good luck.

-Ben

On Tue, Jan 24, 2012 at 4:59 PM, Cliff Jones <cjones-539LkxgYNgKpwFb5G8XvHQ@public.gmane.org> wrote:
Cliff Jones <cjones <at> ...> writes:

>
> Erik Remmelzwaal <jhf.remmelzwaal <at> ...> 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 <cjones <at> 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
>

Here is another piece of the puzzle.  It appears the event is happening inside
of the StripesDispatcher servlet:

2012-01-23 13:50:03,714 ERROR [org.apache.catalina.core.ContainerBase.
[jboss.web].[localhost].[/].[StripesDispatcher]] (ajp-144.226.221.212-8009-1)
Servlet.service() for servlet StripesDispatcher threw exception
java.lang.StackOverflowError
       at
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:220)
       at
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
       at
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
       at
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
       at
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
       at
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:222)
       at


------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/stripes-users
Cliff Jones | 25 Jan 16:12 2012

Re: StackOverflowError on JBoss EAP 5.1

Ben Gunter <bgunter <at> ...> writes:

> 
> 
> This does look vaguely familiar to me, but I don't recall when or where it 
happened or how I fixed or worked around it. How's that for some valuable 
insight? ;)
> 
> The stack trace indicates this is happening completely within Tomcat. Though 
it could be Stripes that somehow triggers the behavior, it would be tough to 
call it a "Stripes problem." Looking at line 222 of the source code 
for ApplicationHttpRequest here ...
> 
> 

As per the Apache post, I verified that the application is doing no request 
wrapping, and can only assume that Stripes is.

2012-01-23 13:50:03,714 ERROR [org.apache.catalina.core.ContainerBase.
[jboss.web].[localhost].[/].[StripesDispatcher]] (ajp-144.226.221.212-8009-1) 
Servlet.service() for servlet StripesDispatcher threw exception
java.lang.StackOverflowError
	at 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
est.java:220)
	at 

The other consideration is that there is a bug in JBoss (not impossible I'm 
sure) which is causing it.

I'm still working on getting the beginning of the stack trace, but it's tough 
because not all the log lines are printed.  My next step is to put a filter in 
front of Stripes and attempt to capture HTTP headers and params in order to 
narrow down the scope of the triggering event.

> 
> 
> 
http://www.docjar.com/html/api/org/apache/catalina/core/ApplicationHttpRequest.j
ava.html
> 
> 
> ... you can see that #getAttribute(String) 
calls getRequest().getAttribute(name). The very next stack frame points, again, 
to line 222 of the same file. That indicates that the wrapper has somehow 
wrapped itself. I have no idea how that could happen.
> 
> 
> 
> It would be very helpful if you could let us know what's going on in your app 
and/or in Stripes before this infinite recursion starts. Even more helpful, if 
you know how to reproduce the problem, would be to put together a small test app 
to demonstrate it. I won't be available to help for the next several days, but 
there might be someone on the list who would find this interesting enough to 
tackle with a little direction.
> 
> 
> Good luck.
> 
> -Ben
> 
> 
> On Tue, Jan 24, 2012 at 4:59 PM, Cliff Jones <cjones-
539LkxgYNgKpwFb5G8XvHQ <at> public.gmane.org> wrote:
> Cliff Jones <cjones <at> ...> writes:
> >
> > Erik Remmelzwaal <jhf.remmelzwaal <at> ...> 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 <cjones <at> 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
> >
> Here is another piece of the puzzle.  It appears the event is happening inside
> of the StripesDispatcher servlet:2012-01-23 13:50:03,714 ERROR 
[org.apache.catalina.core.ContainerBase.
> [jboss.web].[localhost].[/].[StripesDispatcher]] (ajp-144.226.221.212-8009-
1)Servlet.service() for servlet StripesDispatcher threw exception
> java.lang.StackOverflowError
>         at
> 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
> est.java:220)
>         at
> 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
> est.java:222)
>         at
> 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
> est.java:222)
>         at
> 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
> est.java:222)
>         at
> 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
> est.java:222)
>         at
> 
org.apache.catalina.core.ApplicationHttpRequest.getAttribute(ApplicationHttpRequ
> est.java:222)
>         at
> 
> ------------------------------------------------------------------------------
> 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 listStripes-users <at> 
lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/stripes-users
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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 <at> ...
> https://lists.sourceforge.net/lists/listinfo/stripes-users
> 

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Gmane