[jboss-jira] [JBoss JIRA] Updated: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
Adrian Brock (JIRA)
jira-events at jboss.com
Mon Aug 7 08:42:12 EDT 2006
[ http://jira.jboss.com/jira/browse/JBAS-3468?page=all ]
Adrian Brock updated JBAS-3468:
-------------------------------
Fix Version/s: JBossAS-4.0.5.GA
This needs fixing for 4.0.5.GA
> JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBAS-3468
> URL: http://jira.jboss.com/jira/browse/JBAS-3468
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMS service
> Affects Versions: JBossAS-4.0.2 Final
> Environment: Windows XP
> Reporter: Francis Labaere
> Priority: Minor
> Fix For: JBossAS-4.0.5.GA
>
>
> When creating a JMS connection using HTTPConnectionFactory for a user without preconfigured ClientID, mq.Connection starts the ping thread before the ClientID of the Connection is set (explicitely using setClientID or implicitely). The ping thread starts pinging the server with ConnectionToken/@ClientID equal to null.
> The ClientMonitorInterceptor adds this ConnectionToken to its clients HashMap. When the ClientID of the Connection is set (e.g. to XXX) later, the next call to the server will add the updated ConnectionToken to the ClientMonitorInterceptor's clients HashMap with the same SessionID as the previous one. When the ClientMonitorInterceptor checks timedout clients, it will close the session for the first ConnectionToken. Subsequent calls to the server will generate exceptions: User session is not valid.
> On the JBoss server, the ClientMonitorInterceptor closes the client with ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Checking for timedout clients.
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Disconnecting client due to inactivity timeout: ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientIL] close()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] getInstance()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] put(HTTPILRequest asynchClose(), String 105)
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.il.http.HTTPClientILStorageQueue] ClientIL #105 has existing storage queue, adding request to it.
> Later (e.g. after sending a JMS message) the SecurityInterceptor checks the connection with the same sessionID ,but different ClientID: ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.security.ServerSecurityInterceptor] Checking receive authorize on ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] EXCEPTION : receive:
> javax.jms.JMSSecurityException: User session is not valid
> at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] RETURN : receive
> 2006-08-04 13:17:57,294 DEBUG [org.jboss.mq.il.http.servlet.HTTPServerILServlet] Threw an exception of type 'javax.jms.JMSSecurityException' with a message of 'User session is not valid.' This exception is being propogated to the client as a HTTPILResponse.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] doPost() defers to processRequest, see the parameters in its trace.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] processRequest(HttpServletRequest org.apache.catalina.connector.RequestFacade at 2bac2b, HttpServletResponse org.apache.catalina.connector.ResponseFacade at 1343c2a)
> On the Client side: following stacktrace is visible
> 13:17:57 [MessageListenerThread - MyTopic] WARN org.jboss.mq.SpyMessageConsumer - Message consumer closing due to error in listening thread.
> javax.jms.JMSSecurityException: User session is not valid
> at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
> mq.Connection should start the ping thread after the ClientID is known.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list