7 Replies Latest reply on Apr 28, 2009 10:22 PM by timfox

Servlet transport problem

gaohoward Apr 9, 2009 8:06 AM

Hi, I can't get the servlet transport working. I configured a new connection factory that using servlet transport, like:

 <connection-factory name="ServletConnectionFactory">
 <connector-ref connector-name="netty-servlet"/>
 <entry name="ServletConnectionFactory"/>
 <entry name="/ServletConnectionFactory"/>
 <entry name="/XAServletConnectionFactory"/>
 <entry name="java:/ServletConnectionFactory"/>
 <entry name="java:/ServletConnectionFactory"/>
 </connection-factory>

and the netty-servlet configuration is like

 <connector name="netty-servlet">
 <factory-class>org.jboss.messaging.integration.transports.netty.NettyConnectorFactory</factory-class>
 <param key="jbm.remoting.netty.host" value="localhost" type="String"/>
 <param key="jbm.remoting.netty.port" value="8080" type="Integer"/>
 <param key="jbm.remoting.netty.useservlet" value="true" type="Boolean"/>
 <param key="jbm.remoting.netty.servletpath" value="/jms-servlet/JBMServlet" type="String"/>
 </connector>

After I deployed the war that contains the servlet (web.xml), I run my simple example, and it got exception in create connection, here is the output:

runExample:
 [java] ------------uri: http://localhost:8080/jms-servlet/JBMServlet
 [java] ------------------connection create ok.
 [java] Apr 9, 2009 7:48:17 PM org.jboss.messaging.core.logging.Logger warn
 [java] WARNING: Connection failure has been detected Netty exception:0
 [java] java.lang.InterruptedException
 [java] at org.jboss.netty.util.LinkedTransferQueue.take(LinkedTransferQueue.java:565)
 [java] at org.jboss.netty.channel.socket.http.HttpTunnelingClientSocketChannel.receiveChunk(HttpTunnelingClientSocketChannel.java:181)
 [java] at org.jboss.netty.channel.socket.http.HttpTunnelWorker.run(HttpTunnelWorker.java:66)
 [java] at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
 [java] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
 [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
 [java] at java.lang.Thread.run(Thread.java:595)
 [java] Exception in thread "Thread-1 (group:jbm-netty-connector-worker-threads-33414193)" java.lang.NullPointerException
 [java] at org.jboss.netty.buffer.ChannelBuffers.wrappedBuffer(ChannelBuffers.java:242)
 [java] at org.jboss.netty.buffer.ChannelBuffers.wrappedBuffer(ChannelBuffers.java:232)
 [java] at org.jboss.netty.channel.socket.http.HttpTunnelWorker.run(HttpTunnelWorker.java:75)
 [java] at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
 [java] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
 [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
 [java] at java.lang.Thread.run(Thread.java:595)
 [java] Exception in thread "main" javax.jms.JMSException: Timed out waiting for response when sending packet 30
 [java] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.sendBlocking(RemotingConnectionImpl.java:1186)
 [java] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.createSession(ConnectionManagerImpl.java:310)
 [java] at org.jboss.messaging.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:870)
 [java] at org.jboss.messaging.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:579)
 [java] at org.jboss.messaging.jms.client.JBossConnection.authorize(JBossConnection.java:504)
 [java] at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:649)
 [java] at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:441)
 [java] at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:436)
 [java] at org.jboss.javaee.example.ServletTransportExample.main(ServletTransportExample.java:56)
 [java] Caused by: MessagingException[errorCode=3 message=Timed out waiting for response when sending packet 30]
 [java] ... 9 more
 [java] Java Result: 1

undeploy-servlet:
 [delete] Deleting directory /home/howard/apps/jboss-5.1.0.CR1/server/jbm2_default/deploy/jms-servlet.war

Looks like a netty problem, I have no idea so far. Anybody can give a hint? thanks.

1. Re: Servlet transport problem

gaohoward Apr 27, 2009 12:16 AM (in response to gaohoward)

For record:

Trustin has fix the issue in netty, currently in netty trunk now. So it will work with next BETA of netty (BETA3)

Also there is a related bug
https://jira.jboss.org/jira/browse/JBAS-6814

The servlet example can reproduce this bug.
Actions
2. Re: Servlet transport problem

ataylor Apr 27, 2009 12:44 AM (in response to gaohoward)

Trustin has fix the issue in netty, currently in netty trunk now. So it will work with next BETA of netty (BETA3)

Howard, have you tested the fix?
Actions
3. Re: Servlet transport problem

trustin Apr 27, 2009 4:39 PM (in response to gaohoward)

I did preliminary tests, but I believe it needs more test since I made small modifications in HttpTunnelingServlet since my last test.

Also, we need to make sure the tunneling client doesn't trigger JBAS-6814.
Actions

4. Re: Servlet transport problem

trustin Apr 28, 2009 5:53 PM (in response to gaohoward)

The tunneling client now works fine without JBAS-6814 fixed - CPU stays calm.

One remaining question though is: why are two HTTP connections created when I run the 'servlet-transport' example?

The first connection is created by ConnectionFactory.createConnection() in step 4, and the second connection is created by Connection.createSession() in step 5. Is this expected? It seems like the two connections are closed correctly in the end though.

AND I also have found a different issue perhaps related with JBossWeb. It throws NPE on undeploy:

10:10:08,230 WARNING [HttpTunnelingChannelHandler] Unexpected exception
java.lang.NullPointerException
 at org.apache.catalina.session.StandardSession.expire(StandardSession.java:730)
 at org.apache.catalina.session.StandardSession.expire(StandardSession.java:660)
 at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1115)
 at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:150)
 at org.jboss.netty.channel.socket.http.HttpTunnelingChannelHandler.channelClosed(HttpTunnelingChannelHandler.java:144)
 at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:105)
 at org.jboss.netty.channel.Channels.fireChannelClosed(Channels.java:564)
 at org.jboss.netty.channel.local.DefaultLocalChannel.closeNow(DefaultLocalChannel.java:102)
 at org.jboss.netty.channel.local.LocalClientChannelSink.eventSunk(LocalClientChannelSink.java:66)
 at org.jboss.netty.channel.Channels.close(Channels.java:1043)
 at org.jboss.netty.channel.AbstractChannel.close(AbstractChannel.java:185)
 at org.jboss.netty.channel.socket.http.HttpTunnelingServlet.streamResponse(HttpTunnelingServlet.java:99)
 at org.jboss.netty.channel.socket.http.HttpTunnelingServlet.doRequest(HttpTunnelingServlet.java:62)
 at org.jboss.netty.channel.socket.http.HttpTunnelingServlet.doPost(HttpTunnelingServlet.java:195)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 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:235)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
 at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
 at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
 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:158)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Thread.java:619)

Of course, it does not affect JBM because the connections were closed already.

5. Re: Servlet transport problem

trustin Apr 28, 2009 6:01 PM (in response to gaohoward)

Filed a JIRA issue - https://jira.jboss.org/jira/browse/JBWEB-139
Actions
6. Re: Servlet transport problem

gaohoward Apr 28, 2009 10:17 PM (in response to gaohoward)

Verified that the servlet-transport works.

I build AS 5 from latest Branch_5x and build netty from trunk.

And I didn't see any issue, including the undeploy NPE.
Actions
7. Re: Servlet transport problem

timfox Apr 28, 2009 10:22 PM (in response to gaohoward)

"trustin" wrote:

One remaining question though is: why are two HTTP connections created when I run the 'servlet-transport' example?

The first connection is created by ConnectionFactory.createConnection() in step 4, and the second connection is created by Connection.createSession() in step 5. Is this expected? It seems like the two connections are closed correctly in the end though.

If you're using JMS, the JMS connection factory will create a core session for authentication.

Previously we were creating a whole new netty connector per core session, now we share a netty connector for all sessions created from a connection manager, so you shouldn't see two netty http connections any more, if you update from svn and try again.
Actions

Go to original post