StackOverflowError on JBoss EAP 5.1

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

StackOverflowError on JBoss EAP 5.1

avidity
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: StackOverflowError on JBoss EAP 5.1

Erik Remmelzwaal-2
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 <[hidden email]>
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?

----------
<a href="tel:2012-01-23%2013" value="+12012012313">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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: StackOverflowError on JBoss EAP 5.1

avidity
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 <[hidden email]>
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: StackOverflowError on JBoss EAP 5.1

avidity
Cliff Jones <cjones@...> writes:

>
> 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 <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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: StackOverflowError on JBoss EAP 5.1

Ben Gunter
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 <[hidden email]> wrote:
Cliff Jones <cjones@...> writes:

>
> 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 <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?
> > ----------<a href="tel:2012-01-23%2013" value="+12012012313">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-
> <a href="http://jboss.corp.sprint.com/|Mozilla/5.0" target="_blank">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:

<a href="tel:2012-01-23%2013" value="+12012012313">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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: StackOverflowError on JBoss EAP 5.1

avidity
Ben Gunter <bgunter@...> 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-
[hidden email]> 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@...
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users