[JBoss JIRA] Created: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
6:32 a.m.
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
Assigned To: Adrian Brock
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@2bac2b,
HttpServletResponse org.apache.catalina.connector.ResponseFacade@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
6:48 a.m.
New subject: [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
[ http://jira.jboss.com/jira/browse/JBAS-3468?page=all ]
Dimitris Andreadis updated JBAS-3468:
-------------------------------------
Fix Version/s: (was: JBossAS-4.0.5.GA)
Please, don't set the fix version
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
Assigned To: Adrian Brock
Priority: Minor
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@2bac2b,
HttpServletResponse org.apache.catalina.connector.ResponseFacade@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
7:40 a.m.
New subject: [JBoss JIRA] Assigned: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
[ http://jira.jboss.com/jira/browse/JBAS-3468?page=all ]
Adrian Brock reassigned JBAS-3468:
----------------------------------
Assignee: (was: Adrian Brock)
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
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@2bac2b,
HttpServletResponse org.apache.catalina.connector.ResponseFacade@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
7:40 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
[ http://jira.jboss.com/jira/browse/JBAS-3468?page=comments#action_12340737 ]
Adrian Brock commented on JBAS-3468:
------------------------------------
The fundamental problem is that it is creating two entries in the HashMap
one with the client id, the other without.
The one without eventually times out since the ping (and other traffic) is arriving
with the correct client id.
The correct fix would be alter getClientStats()
such that if it fails to find the state, it first iterates over the existing states
to try to match the sesion id.
If it matches, it should update the client id with the correct client id, rather
than creating a new one.
This alogrithm could be optimized by keeping a seperate map of connection tokens
that don't yet have a client id.
Care to try to fix it that way and provide a patch?
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
Assigned To: Adrian Brock
Priority: Minor
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@2bac2b,
HttpServletResponse org.apache.catalina.connector.ResponseFacade@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
7:42 a.m.
New subject: [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
[ 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@2bac2b,
HttpServletResponse org.apache.catalina.connector.ResponseFacade@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
8:10 a.m.
New subject: [JBoss JIRA] Assigned: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
[ http://jira.jboss.com/jira/browse/JBAS-3468?page=all ]
Adrian Brock reassigned JBAS-3468:
----------------------------------
Assignee: Adrian Brock
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
Assigned To: Adrian Brock
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@2bac2b,
HttpServletResponse org.apache.catalina.connector.ResponseFacade@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
12:08 a.m.
New subject: [JBoss JIRA] Closed: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
[ http://jira.jboss.com/jira/browse/JBAS-3468?page=all ]
Adrian Brock closed JBAS-3468.
------------------------------
Fix Version/s: JBossAS-5.0.0.Beta
Resolution: Done
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
Assigned To: Adrian Brock
Priority: Minor
Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
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@2bac2b,
HttpServletResponse org.apache.catalina.connector.ResponseFacade@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
8:56 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
[ http://jira.jboss.com/jira/browse/JBAS-3468?page=comments#action_12385657 ]
ju wonders commented on JBAS-3468:
----------------------------------
The problem is still exists.
The Jboss application sever version is jboss-4.0.5.GA.
This time the exception is throwed at 245 line ofSecurityManager.
javaThe exception stack as follows:
javax.jms.JMSSecurityException: User session is not valid
at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:245)
at
org.jboss.mq.security.ServerSecurityInterceptor.authorizeWrite(ServerSecurityInterceptor.java:264)
at
org.jboss.mq.security.ServerSecurityInterceptor.addMessage(ServerSecurityInterceptor.java:166)
at org.jboss.mq.server.TracingInterceptor.addMessage(TracingInterceptor.java:226)
at org.jboss.mq.server.JMSServerInvoker.addMessage(JMSServerInvoker.java:112)
at sun.reflect.GeneratedMethodAccessor114.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:248)
at
org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:295)
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:96)
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.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:534)
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
Assigned To: Adrian Brock
Priority: Minor
Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta1
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@2bac2b,
HttpServletResponse org.apache.catalina.connector.ResponseFacade@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
6:51 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
[ http://jira.jboss.com/jira/browse/JBAS-3468?page=comments#action_12385981 ]
Adrian Brock commented on JBAS-3468:
------------------------------------
First, it is pointless updating this issue since it is in closed release.
This issue will not change nor will the 4.0.5 release.
Second, the security error message is generic and does not always mean what this issue is
about.
This issue is about when that error message occurs spuriously because of the
ClientMonitorInterceptor
remembers the wrong client id when a race condition goes bad.
Third, there is a test for the problem reported here which passes in 4.0.5:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/tags/JBoss_4_0_5_GA/te...
This test shows even when the race condition goes in the bad direction, the correct client
id is always used.
You need to open a new bug report and provide a test that explains how your issue
differs from this test, or failing that, post the TRACE logging on the server when the
problem occurs.
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
Assigned To: Adrian Brock
Priority: Minor
Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta1
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@2bac2b,
HttpServletResponse org.apache.catalina.connector.ResponseFacade@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
6267
days inactive
6725
days old
8 comments
5 participants
participants (5)
-
Adrian Brock (JIRA) -
Adrian Brock (JIRA) -
Dimitris Andreadis (JIRA)
-
Francis Labaere (JIRA)
-
ju wonders (JIRA)