java.lang.NullPointerException with urlrewrite + spring security 2.0.4 ?

72 views
Skip to first unread message

Hendy Irawan

unread,
Dec 4, 2009, 5:39:58 AM12/4/09
to cometd-users
Hi,

I'm using cometd 1.0.0rc0 with urlrewrite and spring security 2.0.4,
on Tomcat 6.0.20 with native APR and Http11NioProtocol. Sometimes
(sigh) it throws exception as below:

Dec 4, 2009 5:29:26 PM org.apache.catalina.core.StandardWrapperValve
invoke
SEVERE: Servlet.service() for servlet Cometd threw exception
java.lang.NullPointerException
at org.eclipse.jetty.continuation.Jetty6Continuation.resume
(Jetty6Continuation.java:126)
at org.cometd.server.continuation.ContinuationClient.resume
(ContinuationClient.java:144)
at org.cometd.server.ClientImpl.remove(ClientImpl.java:350)
at org.cometd.server.continuation.ContinuationClient.remove
(ContinuationClient.java:192)
at org.cometd.server.AbstractBayeux$DisconnectHandler.handle
(AbstractBayeux.java:1155)
at org.cometd.server.AbstractBayeux.handle(AbstractBayeux.java:282)
at org.cometd.server.continuation.ContinuationCometdServlet.service
(ContinuationCometdServlet.java:134)
at org.cometd.server.AbstractCometdServlet.service
(AbstractCometdServlet.java:250)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke
(ApplicationDispatcher.java:646)
at org.apache.catalina.core.ApplicationDispatcher.processRequest
(ApplicationDispatcher.java:436)
at org.apache.catalina.core.ApplicationDispatcher.doForward
(ApplicationDispatcher.java:374)
at org.apache.catalina.core.ApplicationDispatcher.forward
(ApplicationDispatcher.java:302)
at org.tuckey.web.filters.urlrewrite.NormalRewrittenUrl.doRewrite
(NormalRewrittenUrl.java:195)
at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite
(RuleChain.java:159)
at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:
141)
at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest
(UrlRewriter.java:90)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter
(UrlRewriteFilter.java:417)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:378)
at
org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke
(FilterSecurityInterceptor.java:109)
at
org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter
(FilterSecurityInterceptor.java:83)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at
org.springframework.security.ui.SessionFixationProtectionFilter.doFilterHttp
(SessionFixationProtectionFilter.java:67)
at org.springframework.security.ui.SpringSecurityFilter.doFilter
(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at
org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp
(ExceptionTranslationFilter.java:101)
at org.springframework.security.ui.SpringSecurityFilter.doFilter
(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at
org.springframework.security.providers.anonymous.AnonymousProcessingFilter.doFilterHttp
(AnonymousProcessingFilter.java:105)
at org.springframework.security.ui.SpringSecurityFilter.doFilter
(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at
org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp
(RememberMeProcessingFilter.java:116)
at org.springframework.security.ui.SpringSecurityFilter.doFilter
(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at
org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp
(SecurityContextHolderAwareRequestFilter.java:91)
at org.springframework.security.ui.SpringSecurityFilter.doFilter
(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at
org.springframework.security.ui.basicauth.BasicProcessingFilter.doFilterHttp
(BasicProcessingFilter.java:174)
at org.springframework.security.ui.SpringSecurityFilter.doFilter
(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at
org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp
(AbstractProcessingFilter.java:277)
at org.springframework.security.ui.SpringSecurityFilter.doFilter
(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp
(LogoutFilter.java:89)
at org.springframework.security.ui.SpringSecurityFilter.doFilter
(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at
org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp
(HttpSessionContextIntegrationFilter.java:235)
at org.springframework.security.ui.SpringSecurityFilter.doFilter
(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:390)
at org.springframework.security.util.FilterChainProxy.doFilter
(FilterChainProxy.java:175)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate
(DelegatingFilterProxy.java:236)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter
(DelegatingFilterProxy.java:167)
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:233)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11NioProcessor.process
(Http11NioProcessor.java:883)
at org.apache.coyote.http11.Http11NioProtocol
$Http11ConnectionHandler.process(Http11NioProtocol.java:722)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run
(NioEndpoint.java:2214)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

I wonder if this is a normal error, or issue with either cometd,
urlrewrite, spring security ?

Thank you.

Simone Bordet

unread,
Dec 4, 2009, 6:21:20 AM12/4/09
to cometd...@googlegroups.com
Hi,

On Fri, Dec 4, 2009 at 11:39, Hendy Irawan <he...@soluvas.com> wrote:
> Hi,
>
> I'm using cometd 1.0.0rc0 with urlrewrite and spring security 2.0.4,
> on Tomcat 6.0.20 with native APR and Http11NioProtocol. Sometimes
> (sigh) it throws exception as below:

Did you install the ContinuationFilter ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

Hendy Irawan

unread,
Dec 4, 2009, 6:50:45 AM12/4/09
to cometd-users
Yes I did.

I tried moving the ContinuationFilter to the top of web.xml, but it
still give the error.

Exception during handling of response Conversion Error null, typeof
object

From Dojo cometd client, some of the error message received is:

0 : {
successful : false,
error : 402::Unknown client,
advice : {
reconnect : handshake,
interval : 500
},
channel : /messages
}

Moving urlrewrite filter out solves the problem (spring security
filter is still enabled). So I guess Spring Security is not guilty.

Simone Bordet

unread,
Dec 4, 2009, 7:53:12 AM12/4/09
to cometd...@googlegroups.com
Hi,

On Fri, Dec 4, 2009 at 12:50, Hendy Irawan <he...@soluvas.com> wrote:
> Yes I did.
>
> I tried moving the ContinuationFilter to the top of web.xml, but it
> still give the error.
>
> Exception during handling of response Conversion Error null, typeof
> object
>
> From Dojo cometd client, some of the error message received is:
>
>        0 : {
>                successful : false,
>                error : 402::Unknown client,
>                advice : {
>                        reconnect : handshake,
>                        interval : 500
>                },
>                channel : /messages
>        }
>
> Moving urlrewrite filter out solves the problem (spring security
> filter is still enabled). So I guess Spring Security is not guilty.

So it was the URL Rewrite Filter ?

Hendy Irawan

unread,
Dec 4, 2009, 2:35:12 PM12/4/09
to cometd-users
Yes I reported it to urlrewrite mailing list.

Here's the thread: http://groups.google.com/group/urlrewrite/browse_thread/thread/a01db983ab81220d

And his reply;
==
> It seems that UrlRewrite interferes with filters using continuation or
> perhaps with NIO.

Nope. The URF "forwards" a request once a URL for a matching rule is
"re-written". This essentially means that the request is dispatched to
a new
location. Web application filters, typically, are configured to be
listening
only on request's and NOT forwards.

I'm trying to use cometd servlet, that requires ContinuationFilter
under
> Tomcat 6.0.20. With urlrewrite filter enabled, it sometimes give errors.
> Disabling urlrewrite filter (or using it for different url-pattern) solves
> the problem.

In light of what I said above, if you add the underneath to your
ContinuationFilter's filter-mapping in web.xml, it would be called
even when
the request is forwarded via a dispatcher.
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>

Let me know, if this resolves the issue.

Cheers
Avlesh
==

What's the most correct way to install the ContinuationFilter ? Is it
in the docs ?

Simone Bordet

unread,
Dec 14, 2009, 4:06:06 AM12/14/09
to cometd...@googlegroups.com
Hi,
The correct way to use the ContinuationFilter is to map it to REQUEST
only, since you don't want the ContinuationFilter to be triggered for
every forward.
Can you try to configure the listeners so that it will result:

request --> ContinuationFilter --> RewriteFilter --> forward -->
ContinuationCometdServlet

and tell us if it works ?

Alternatively, you may want to look at Jetty's rewrite handler:
http://wiki.eclipse.org/Jetty/Feature/Rewrite_Handler

Pedro Teixeira

unread,
Jan 5, 2010, 9:18:55 AM1/5/10
to cometd-users

I'm getting the "402::Unknown client" message under high load only.

I have to stress cases: A) 8 msgs / sec B) 1000 msgs /sec.
The error only happens in case B. After it happens, the client
callbacks are not longer fired (i.e. it does not recover). It seems
the server looses track of that client.

Anyone might known what's going on?

cheers,
Pedro


On Dec 4 2009, 10:53 am, Simone Bordet <simone.bor...@gmail.com>
wrote:


> Hi,
>
> On Fri, Dec 4, 2009 at 12:50, Hendy Irawan <he...@soluvas.com> wrote:
> > Yes I did.
>
> > I tried moving the ContinuationFilter to the top of web.xml, but it
> > still give the error.
>
> > Exception during handling of response Conversion Error null, typeof
> > object
>
> > From Dojo cometd client, some of the error message received is:
>
> >        0 : {
> >                successful : false,
> >                error : 402::Unknown client,
> >                advice : {
> >                        reconnect : handshake,
> >                        interval : 500
> >                },
> >                channel : /messages
> >        }
>
> > Moving urlrewrite filter out solves the problem (spring security
> > filter is still enabled). So I guess Spring Security is not guilty.
>
> So it was the URL Rewrite Filter ?
>
> Simon

> --http://bordet.blogspot.com

Reply all
Reply to author
Forward
0 new messages