Re: T5: Multiple clicks causing NPE
I've added https://issues.apache.org/jira/browse/TAPESTRY-2037 On Jan 8, 2008 4:47 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I'll have to look into whether there is a workaround for that > ThreadLocal bug, and figure out a way to test this. > > > On Jan 8, 2008 2:08 PM, jason lea <[EMAIL PROTECTED]> wrote: > > Hi, > > > > We get this error quite often with Java 1.5, we asked about it in the > > mailing list back in August. We found the error doesn't occur in Java 1.6. > > We usually see a stack trace with a NPE when doing getSession() or > > getCookies(). > > > > Here is what I wrote last time: > > > > We are getting an intermittent NullPointerException in Tapestry 5.0.5. We > > are running on Java 1.5. > > It seems that the RequestGlobals has a null Request when the call to > > getCookies is made (or that RequestGlobals is null). We cannot get the > > error to occur every time so testing is tricky, sometimes it occurs on the > > first request after the webapp starts with subsequent requests good for a > > few minutes before it occurs again. Other times it starts fine and pressing > > F5 100 times might make it occur. > > > > Our thought at the moment is that a ThreadLocal bug ( > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6550283 ) might be > > causing the RequestGlobals to initially be correctly initialised and stored > > in ThreadLocal but later on with more items being added this bug means > > further down the track, a new RequestGlobals is added with null values. > > > > > > > > -- > > Jason Lea > > > > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Multiple clicks causing NPE
I'll have to look into whether there is a workaround for that ThreadLocal bug, and figure out a way to test this. On Jan 8, 2008 2:08 PM, jason lea <[EMAIL PROTECTED]> wrote: > Hi, > > We get this error quite often with Java 1.5, we asked about it in the > mailing list back in August. We found the error doesn't occur in Java 1.6. > We usually see a stack trace with a NPE when doing getSession() or > getCookies(). > > Here is what I wrote last time: > > We are getting an intermittent NullPointerException in Tapestry 5.0.5. We > are running on Java 1.5. > It seems that the RequestGlobals has a null Request when the call to > getCookies is made (or that RequestGlobals is null). We cannot get the > error to occur every time so testing is tricky, sometimes it occurs on the > first request after the webapp starts with subsequent requests good for a > few minutes before it occurs again. Other times it starts fine and pressing > F5 100 times might make it occur. > > Our thought at the moment is that a ThreadLocal bug ( > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6550283 ) might be > causing the RequestGlobals to initially be correctly initialised and stored > in ThreadLocal but later on with more items being added this bug means > further down the track, a new RequestGlobals is added with null values. > > > > -- > Jason Lea > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: Multiple clicks causing NPE
Hi, We get this error quite often with Java 1.5, we asked about it in the mailing list back in August. We found the error doesn't occur in Java 1.6. We usually see a stack trace with a NPE when doing getSession() or getCookies(). Here is what I wrote last time: We are getting an intermittent NullPointerException in Tapestry 5.0.5. We are running on Java 1.5. It seems that the RequestGlobals has a null Request when the call to getCookies is made (or that RequestGlobals is null). We cannot get the error to occur every time so testing is tricky, sometimes it occurs on the first request after the webapp starts with subsequent requests good for a few minutes before it occurs again. Other times it starts fine and pressing F5 100 times might make it occur. Our thought at the moment is that a ThreadLocal bug ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6550283 ) might be causing the RequestGlobals to initially be correctly initialised and stored in ThreadLocal but later on with more items being added this bug means further down the track, a new RequestGlobals is added with null values. -- Jason Lea
Re: T5: Multiple clicks causing NPE
The test was with 5.0.7.
On 09/01/2008, at 5:48 AM, Robert Zeigler wrote:
I've seen this same stack trace from pretty early on, but I never
had time to track down the issue... I figured it was a threading
issue, to be honest, and I wasn't convinced that it wasn't my code
that was at fault. But if you look at
http://issues.apache.org/jira/browse/TAPESTRY-1658
I posted the same stack trace there. I'm seeing this in two
separate apps now, one fairly complicated app, and one extremely
trivial one. I should back up a bit on the trivial app; I haven't
personally seen it, but I'm now hearing reports from users that they
are seeing it on occasion; they didn't use to, but the app usage is
picking up now, so...
I've seen this in version 5.0.3, 5.0.4, 5.0.5, and also in 5.0.6.
The info that Geof provided sounds about right, as the more
complicated app has more long-running procedures.
Sorry I don't have more info than that, but I've had my own series
of issues to deal with that have been more pressing than an
intermittent NPE.
Robert
On Jan 8, 2008, at 1/812:16 PM , Howard Lewis Ship wrote:
That doesn't look good .. but it is an earlier version of the
framework, looks like 5.0.3 or 5.0.4.
Looks like its hitting this code:
public CookieSource buildCookieSource()
{
return new CookieSource()
{
public Cookie[] getCookies()
{
return
_requestGlobals.getHTTPServletRequest().getCookies();
}
};
}
That should be pretty bullet proof, since the _requestGlobals field
is
final and set in the constructor. I'm not sure what other changes
may
have affected this situation in the intervening releases.
On Jan 8, 2008 4:09 AM, Geoff Callender
<[EMAIL PROTECTED]> wrote:
While trying to demonstrate the dangers of multiple submits, I found
Tapestry throwing NullPointerException.
Can someone who understands Tapestry's internals shed some light on
this?
To make the test possible, I emulated a slow operation by sleeping 2
seconds. The NPE then occurred on the 3rd or later click - it
varied
quite a bit. Here's how I emulated the slow operation...
@ApplicationState
private MyOrder _myOrder;
Object onSuccess() {
sleep(2000); // Sleep 2 seconds to simulate slow
transaction
int newQuantity = _myOrder.getQuantity() + 1;
_myOrder.setQuantity(newQuantity);
return _page2;
}
private void sleep(long duration) {
try {
Thread.sleep(duration);
}
catch (InterruptedException e) {
}
}
Here's the exception...
22:45:53,443 ERROR [RequestExceptionHandler] Processing of request
failed with uncaught exception: java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.tapestry.internal.services.InternalModule
$2.getCookies(InternalModule.java:307)
at
$CookieSource_11759363dd0.getCookies($CookieSource_11759363dd0.java)
at
org
.apache
.tapestry
.internal.services.CookiesImpl.readCookieValue(CookiesImpl.java:53)
at
$Cookies_11759363dcf.readCookieValue($Cookies_11759363dcf.java)
at
org
.apache
.tapestry
.services
.PersistentLocaleImpl.getCookieValue(PersistentLocaleImpl.java:46)
at
org
.apache
.tapestry
.services.PersistentLocaleImpl.get(PersistentLocaleImpl.java:
40)
at
$
PersistentLocale_11759363dce.get($PersistentLocale_11759363dce.java)
at
org
.apache
.tapestry
.internal
.services
.LocalizationSetterImpl
.setThreadLocale(LocalizationSetterImpl.java:98)
at
$
LocalizationSetter_11759363dcb
.setThreadLocale($LocalizationSetter_11759363dcb.java)
at
org
.apache
.tapestry
.internal
.services.LocalizationFilter.service(LocalizationFilter.java:
41)
at
$
RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at org.apache.tapestry.services.TapestryModule
$2.service(TapestryModule.java:688)
at
$
RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at
org
.apache
.tapestry
.internal
.services.StaticFilesFilter.service(StaticFilesFilter.java:84)
at
$
RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at org.apache.tapestry.internal.services.CheckForUpdatesFilter
$2.invoke(CheckForUpdatesFilter.java:97)
at org.apache.tapestry.internal.services.CheckForUpdatesFilter
$2.invoke(CheckForUpdatesFilter.java:88)
at
org
.apache
.tapestry
.ioc
.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:77)
at
org
.apache
.tapestry
.internal
.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:
110)
at
$
RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at
$
RequestHandler_11759363dc6.service($RequestHandler_11759363dc6.java)
at org.apache.tapestry.services.TapestryModule
$12.service(TapestryModule.java:1086)
at
$
HttpServletRequestHandler_11759363dc5
.service($Http
Re: T5: Multiple clicks causing NPE
I've seen this same stack trace from pretty early on, but I never had
time to track down the issue... I figured it was a threading issue, to
be honest, and I wasn't convinced that it wasn't my code that was at
fault. But if you look at
http://issues.apache.org/jira/browse/TAPESTRY-1658
I posted the same stack trace there. I'm seeing this in two separate
apps now, one fairly complicated app, and one extremely trivial one.
I should back up a bit on the trivial app; I haven't personally seen
it, but I'm now hearing reports from users that they are seeing it on
occasion; they didn't use to, but the app usage is picking up now, so...
I've seen this in version 5.0.3, 5.0.4, 5.0.5, and also in 5.0.6.
The info that Geof provided sounds about right, as the more
complicated app has more long-running procedures.
Sorry I don't have more info than that, but I've had my own series of
issues to deal with that have been more pressing than an intermittent
NPE.
Robert
On Jan 8, 2008, at 1/812:16 PM , Howard Lewis Ship wrote:
That doesn't look good .. but it is an earlier version of the
framework, looks like 5.0.3 or 5.0.4.
Looks like its hitting this code:
public CookieSource buildCookieSource()
{
return new CookieSource()
{
public Cookie[] getCookies()
{
return
_requestGlobals.getHTTPServletRequest().getCookies();
}
};
}
That should be pretty bullet proof, since the _requestGlobals field is
final and set in the constructor. I'm not sure what other changes may
have affected this situation in the intervening releases.
On Jan 8, 2008 4:09 AM, Geoff Callender
<[EMAIL PROTECTED]> wrote:
While trying to demonstrate the dangers of multiple submits, I found
Tapestry throwing NullPointerException.
Can someone who understands Tapestry's internals shed some light on
this?
To make the test possible, I emulated a slow operation by sleeping 2
seconds. The NPE then occurred on the 3rd or later click - it varied
quite a bit. Here's how I emulated the slow operation...
@ApplicationState
private MyOrder _myOrder;
Object onSuccess() {
sleep(2000); // Sleep 2 seconds to simulate slow
transaction
int newQuantity = _myOrder.getQuantity() + 1;
_myOrder.setQuantity(newQuantity);
return _page2;
}
private void sleep(long duration) {
try {
Thread.sleep(duration);
}
catch (InterruptedException e) {
}
}
Here's the exception...
22:45:53,443 ERROR [RequestExceptionHandler] Processing of request
failed with uncaught exception: java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.tapestry.internal.services.InternalModule
$2.getCookies(InternalModule.java:307)
at
$CookieSource_11759363dd0.getCookies($CookieSource_11759363dd0.java)
at
org
.apache
.tapestry
.internal.services.CookiesImpl.readCookieValue(CookiesImpl.java:53)
at
$Cookies_11759363dcf.readCookieValue($Cookies_11759363dcf.java)
at
org
.apache
.tapestry
.services
.PersistentLocaleImpl.getCookieValue(PersistentLocaleImpl.java:46)
at
org
.apache
.tapestry
.services.PersistentLocaleImpl.get(PersistentLocaleImpl.java:
40)
at
$PersistentLocale_11759363dce.get($PersistentLocale_11759363dce.java)
at
org
.apache
.tapestry
.internal
.services
.LocalizationSetterImpl.setThreadLocale(LocalizationSetterImpl.java:
98)
at
$
LocalizationSetter_11759363dcb
.setThreadLocale($LocalizationSetter_11759363dcb.java)
at
org
.apache
.tapestry
.internal
.services.LocalizationFilter.service(LocalizationFilter.java:
41)
at
$RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at org.apache.tapestry.services.TapestryModule
$2.service(TapestryModule.java:688)
at
$RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at
org
.apache
.tapestry
.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:
84)
at
$RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at org.apache.tapestry.internal.services.CheckForUpdatesFilter
$2.invoke(CheckForUpdatesFilter.java:97)
at org.apache.tapestry.internal.services.CheckForUpdatesFilter
$2.invoke(CheckForUpdatesFilter.java:88)
at
org
.apache
.tapestry
.ioc
.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:77)
at
org
.apache
.tapestry
.internal
.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:
110)
at
$RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at
$RequestHandler_11759363dc6.service($RequestHandler_11759363dc6.java)
at org.apache.tapestry.services.TapestryModule
$12.service(TapestryModule.java:1086)
at
$
HttpServletRequestHandler_11759363dc5
.service($HttpServletRe
Re: T5: Multiple clicks causing NPE
That doesn't look good .. but it is an earlier version of the
framework, looks like 5.0.3 or 5.0.4.
Looks like its hitting this code:
public CookieSource buildCookieSource()
{
return new CookieSource()
{
public Cookie[] getCookies()
{
return _requestGlobals.getHTTPServletRequest().getCookies();
}
};
}
That should be pretty bullet proof, since the _requestGlobals field is
final and set in the constructor. I'm not sure what other changes may
have affected this situation in the intervening releases.
On Jan 8, 2008 4:09 AM, Geoff Callender
<[EMAIL PROTECTED]> wrote:
> While trying to demonstrate the dangers of multiple submits, I found
> Tapestry throwing NullPointerException.
>
> Can someone who understands Tapestry's internals shed some light on
> this?
>
> To make the test possible, I emulated a slow operation by sleeping 2
> seconds. The NPE then occurred on the 3rd or later click - it varied
> quite a bit. Here's how I emulated the slow operation...
>
> @ApplicationState
> private MyOrder _myOrder;
>
> Object onSuccess() {
> sleep(2000); // Sleep 2 seconds to simulate slow transaction
>
> int newQuantity = _myOrder.getQuantity() + 1;
> _myOrder.setQuantity(newQuantity);
>
> return _page2;
> }
>
> private void sleep(long duration) {
> try {
> Thread.sleep(duration);
> }
> catch (InterruptedException e) {
> }
> }
>
> Here's the exception...
>
> 22:45:53,443 ERROR [RequestExceptionHandler] Processing of request
> failed with uncaught exception: java.lang.NullPointerException
> java.lang.NullPointerException
> at org.apache.tapestry.internal.services.InternalModule
> $2.getCookies(InternalModule.java:307)
> at
> $CookieSource_11759363dd0.getCookies($CookieSource_11759363dd0.java)
> at
> org
> .apache
> .tapestry
> .internal.services.CookiesImpl.readCookieValue(CookiesImpl.java:53)
> at $Cookies_11759363dcf.readCookieValue($Cookies_11759363dcf.java)
> at
> org
> .apache
> .tapestry
> .services
> .PersistentLocaleImpl.getCookieValue(PersistentLocaleImpl.java:46)
> at
> org
> .apache
> .tapestry.services.PersistentLocaleImpl.get(PersistentLocaleImpl.java:
> 40)
> at
> $PersistentLocale_11759363dce.get($PersistentLocale_11759363dce.java)
> at
> org
> .apache
> .tapestry
> .internal
> .services
> .LocalizationSetterImpl.setThreadLocale(LocalizationSetterImpl.java:98)
> at
> $
> LocalizationSetter_11759363dcb
> .setThreadLocale($LocalizationSetter_11759363dcb.java)
> at
> org
> .apache
> .tapestry
> .internal.services.LocalizationFilter.service(LocalizationFilter.java:
> 41)
> at
> $RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
> at org.apache.tapestry.services.TapestryModule
> $2.service(TapestryModule.java:688)
> at
> $RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
> at
> org
> .apache
> .tapestry
> .internal.services.StaticFilesFilter.service(StaticFilesFilter.java:84)
> at
> $RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
> at org.apache.tapestry.internal.services.CheckForUpdatesFilter
> $2.invoke(CheckForUpdatesFilter.java:97)
> at org.apache.tapestry.internal.services.CheckForUpdatesFilter
> $2.invoke(CheckForUpdatesFilter.java:88)
> at
> org
> .apache
> .tapestry
> .ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:77)
> at
> org
> .apache
> .tapestry
> .internal
> .services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:110)
> at
> $RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
> at
> $RequestHandler_11759363dc6.service($RequestHandler_11759363dc6.java)
> at org.apache.tapestry.services.TapestryModule
> $12.service(TapestryModule.java:1086)
> at
> $
> HttpServletRequestHandler_11759363dc5
> .service($HttpServletRequestHandler_11759363dc5.java)
> at
> org.apache.tapestry.TapestryFilter.doFilter(TapestryFilter.java:135)
> at
> org
> .apache
> .catalina
> .core
> .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
> 235)
> at
> org
> .apache
> .catalina
> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org
> .jboss
> .web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:
> 96)
> at
> org
> .apache
> .catalina
> .core
> .ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
> 235)
> at
> org
> .apache
> .catalina
> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org
> .apache
> .catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
> 230)
>
Re: T5: Multiple clicks causing NPE
This is great! We should all be stress testing the framework to reveal these kinds of problems. Easier to fix now than later! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5: Multiple clicks causing NPE
While trying to demonstrate the dangers of multiple submits, I found
Tapestry throwing NullPointerException.
Can someone who understands Tapestry's internals shed some light on
this?
To make the test possible, I emulated a slow operation by sleeping 2
seconds. The NPE then occurred on the 3rd or later click - it varied
quite a bit. Here's how I emulated the slow operation...
@ApplicationState
private MyOrder _myOrder;
Object onSuccess() {
sleep(2000); // Sleep 2 seconds to simulate slow transaction
int newQuantity = _myOrder.getQuantity() + 1;
_myOrder.setQuantity(newQuantity);
return _page2;
}
private void sleep(long duration) {
try {
Thread.sleep(duration);
}
catch (InterruptedException e) {
}
}
Here's the exception...
22:45:53,443 ERROR [RequestExceptionHandler] Processing of request
failed with uncaught exception: java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.tapestry.internal.services.InternalModule
$2.getCookies(InternalModule.java:307)
at $CookieSource_11759363dd0.getCookies($CookieSource_11759363dd0.java)
at
org
.apache
.tapestry
.internal.services.CookiesImpl.readCookieValue(CookiesImpl.java:53)
at $Cookies_11759363dcf.readCookieValue($Cookies_11759363dcf.java)
at
org
.apache
.tapestry
.services
.PersistentLocaleImpl.getCookieValue(PersistentLocaleImpl.java:46)
at
org
.apache
.tapestry.services.PersistentLocaleImpl.get(PersistentLocaleImpl.java:
40)
at
$PersistentLocale_11759363dce.get($PersistentLocale_11759363dce.java)
at
org
.apache
.tapestry
.internal
.services
.LocalizationSetterImpl.setThreadLocale(LocalizationSetterImpl.java:98)
at
$
LocalizationSetter_11759363dcb
.setThreadLocale($LocalizationSetter_11759363dcb.java)
at
org
.apache
.tapestry
.internal.services.LocalizationFilter.service(LocalizationFilter.java:
41)
at
$RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at org.apache.tapestry.services.TapestryModule
$2.service(TapestryModule.java:688)
at
$RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at
org
.apache
.tapestry
.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:84)
at
$RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at org.apache.tapestry.internal.services.CheckForUpdatesFilter
$2.invoke(CheckForUpdatesFilter.java:97)
at org.apache.tapestry.internal.services.CheckForUpdatesFilter
$2.invoke(CheckForUpdatesFilter.java:88)
at
org
.apache
.tapestry
.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:77)
at
org
.apache
.tapestry
.internal
.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:110)
at
$RequestHandler_11759363dcd.service($RequestHandler_11759363dcd.java)
at
$RequestHandler_11759363dc6.service($RequestHandler_11759363dc6.java)
at org.apache.tapestry.services.TapestryModule
$12.service(TapestryModule.java:1086)
at
$
HttpServletRequestHandler_11759363dc5
.service($HttpServletRequestHandler_11759363dc5.java)
at org.apache.tapestry.TapestryFilter.doFilter(TapestryFilter.java:135)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org
.jboss
.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:
96)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org
.apache
.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
230)
at
org
.apache
.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
175)
at
org
.jboss
.web
.tomcat
.security
.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at
org
.jboss
.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at
org
.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
127)
at
org
.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
102)
at
org
.jboss
.web
.tomcat
.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:
157)
at
org
.apache
.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
262)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
844)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
446)
