[JBoss JIRA] Created: (JBAS-4935) CLONE -JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
by ju wonders (JIRA)
CLONE -JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-4935
URL: http://jira.jboss.com/jira/browse/JBAS-4935
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: ju wonders
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
18 years, 6 months
[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
by Francis Labaere (JIRA)
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
18 years, 6 months
[JBoss JIRA] Assigned: (JBAS-2889) AppClientUnitTestCase doesn't clean up if it fails
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2889?page=all ]
Dimitris Andreadis reassigned JBAS-2889:
----------------------------------------
Assignee: Shelly McGowan
If you have time to look at.
> AppClientUnitTestCase doesn't clean up if it fails
> --------------------------------------------------
>
> Key: JBAS-2889
> URL: http://jira.jboss.com/jira/browse/JBAS-2889
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Ryan Campbell
> Assigned To: Shelly McGowan
> Fix For: JBossAS-5.0.0.Beta3
>
>
> The org.jboss.test.client.test.AppClientUnitTestCase deploys a bunch of services but fails to clean them.
> If you run a CMP test before the AppClientUnitTest, it passes, but if you run it immediately after, it fails:
> > ./build.sh one-test -Dtest=org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase
> one-test:
> [junit] Running org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase
> [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 6.04 sec
> > ./build.sh one-test -Dtest=org.jboss.test.client.test.AppClientUnitTestCase
> [junit] Running org.jboss.test.client.test.AppClientUnitTestCase
> [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 3.149 sec
> [junit] Test org.jboss.test.client.test.AppClientUnitTestCase FAILED
> > ./build.sh one-test -Dtest=org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase
> [junit] Running org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase
> [junit] Tests run: 19, Failures: 0, Errors: 19, Time elapsed: 1.05 sec
> [junit] Test org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase FAILED
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBFORUMS-247) forums and commons-fileupload-1.1
by Luca Stancapiano (JIRA)
forums and commons-fileupload-1.1
---------------------------------
Key: JBFORUMS-247
URL: http://jira.jboss.com/jira/browse/JBFORUMS-247
Project: JBoss Forums
Issue Type: Bug
Environment: JBoss as from http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_4_0_5_GA_CP06,
JBoss Portal from http://anonsvn.jboss.org/repos/portal/trunk since 9 july 2007,
JBoss Forums from http://anonsvn.jboss.org/repos/labs/labs/jbossforums/branches/forums101P26 since 9 july 2007
Reporter: Luca Stancapiano
Assigned To: Ryszard Kozmik
Attachments: ForumsJSFPortlet.java
hi....I send you to see http://jira.jboss.com/jira/browse/JBPORTAL-1550 by me reported. It is the same problem......if you post messages using 'multipart/form-data' through commons-fileupload libs, you miss character encoding because there is a incompatibility between tomcat 5.5.23 and fileupload 1.1, and then if you try to send messages with characters as à, è, ì, ò, ù you 'll get problems of decoding with strange characters of response. Also for Forums I send you a patch. I substituted getString() method of org.apache.commons.fileupload.disk.DiskFileItem class with getString( String ...) method, passing inside the character encoding of the request:
org.jboss.portlet.forums.ui.ForumsJSFPortlet : row 560
I write :
newParams.put(item.getFieldName(), new String[]{item.getString(req.getCharacterEncoding())});
instead of:
newParams.put(item.getFieldName(), new String[]{item.getString()});
org.jboss.portlet.forums.ui.ForumsJSFPortlet : row 564
I write:
String value = item.getString(req.getCharacterEncoding());
instead of:
String value = item.getString();
--
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
18 years, 6 months
[JBoss JIRA] Created: (JGRP-535) NAKACK: release lock when message is delivered
by Bela Ban (JIRA)
NAKACK: release lock when message is delivered
----------------------------------------------
Key: JGRP-535
URL: http://jira.jboss.com/jira/browse/JGRP-535
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6
When NAKACK receives a message from C, it gets the NakReceiverWindow for C and acquires a lock on C, and then passes up the message. When the call returns, the lock is received (it is actually currently a synchronized(win) statement).
The reason is that this is needed to deliver all messages from C in the order in which they were sent.
The issue is that, while a message from C is delivered, all other threads are blocked on the lock for C's NakReceiverWindow. Especially the case when an up() method calls down() before returning, and down() blocks, this increases the duration during which the lock is kept. Example:
- Message from C acquires a lock on C's NakReceiverWindow
- Message is passed up
- The application gets the receive() callback
- *Inside* the receive(), the application calls Channel.send() which results in a down()
- Only when the down() placed the message on the network and returned will the up() method unwind its stack and return
--> Result: we kept a lock on C's NRW for much longer than we needed to. The lock should be kept until C's message has been *DELIVERED*, but not until the down() method returns !
--> If FC.down() blocks for credits, this makes it even worse !
SOLUTION:
- Investigate associating the lock acquired in NAKACK for C's NakReceiverWindow with the thread local. When the message is delivered (semantics ?), release the lock, this is sooner than when the up() method returns in NAKACK.
- This could also be done for example in STABLE.handleRegularMessage(), where we send the message up first, the release the lock and *only then* multicast the STABLE message
Investigate UNICAST as well.
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBMICROCONT-155) java.io.IOException: No context factory for vfsfile
by Scott M Stark (JIRA)
java.io.IOException: No context factory for vfsfile
---------------------------------------------------
Key: JBMICROCONT-155
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-155
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
Assigned To: Scott M Stark
Fix For: JBossMC_2_0_0_CR1
The following org.jboss.test.virtual.test.FileVFSUnitTestCase:
/**
* Test that one can go from a file uri to VirtualFile and obtain the
* same VirtualFile using VirtualFile vfsfile uri
* @throws Exception
*/
public void testVFSFileURIFactory()
throws Exception
{
URL rootURL = getClass().getProtectionDomain().getCodeSource().getLocation();
VFS rootVFS0 = VFS.getVFS(rootURL.toURI());
VirtualFile root0 = rootVFS0.getRoot();
VFS rootVFS1 = VFS.getVFS(root0.toURI());
VirtualFile root1 = rootVFS1.getRoot();
assertEquals(root0, root1);
}
fails with:
java.io.IOException: No context factory for vfsfile:/home/svn/JBossMC/vfs/target/test-classes/
at org.jboss.virtual.VFS.getVFS(VFS.java:83)
at org.jboss.test.virtual.test.FileVFSUnitTestCase.testVFSFileURIFactory(FileVFSUnitTestCase.java:104)
The VFSContextFactory uri mappings need to be updated to include the vfs* forms of the known handlers.
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBMICROCONT-205) Accessing content of vfsfile url fails
by Scott M Stark (JIRA)
Accessing content of vfsfile url fails
--------------------------------------
Key: JBMICROCONT-205
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-205
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Reporter: Scott M Stark
Fix For: JBossMC-2.0.0.Beta4
When trying to create a ManagedProperty for a URL type with a vfsfile: url value, the content fails to be obtained:
Caused by: java.net.UnknownServiceException: no content-type
at java.net.URLConnection.getContentHandler(URLConnection.java:1167)
at java.net.URLConnection.getContent(URLConnection.java:683)
at java.net.URL.getContent(URL.java:1021)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
at org.jboss.beans.info.plugins.AbstractPropertyInfo.get(AbstractPropertyInfo.java:172)
at org.jboss.beans.info.plugins.AbstractBeanInfo.getProperty(AbstractBeanInfo.java:238)
at org.jboss.metatype.plugins.values.DefaultMetaValueFactory.createCompositeValue(DefaultMetaValueFactory.java:371)
... 23 more
VirtualFileURLConnection should be overriding the getContent method to return the VirtualFile I suppose.
--
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
18 years, 6 months