April 2011 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1163) Evaluate FindBugs reports

by Ron Sigal (JIRA)

Evaluate FindBugs reports ------------------------- Key: JBREM-1163 URL: https://jira.jboss.org/jira/browse/JBREM-1163 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP1 (Flounder) http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-findbug... and http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.x-findbugs/... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
11
0 / 0

[JBoss JIRA] Created: (JBREM-988) Watch org.jboss.test.remoting.stream.StreamingTestCase for failures

by Ron Sigal (JIRA)

Watch org.jboss.test.remoting.stream.StreamingTestCase for failures ------------------------------------------------------------------- Key: JBREM-988 URL: http://jira.jboss.com/jira/browse/JBREM-988 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.1.Beta org.jboss.test.remoting.stream.StreamingTestCase has failed a few times in hudson. Should watch for more failures. -- 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 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1286) Fix sources encoding to UTF-8

by Ondrej Zizka (JIRA)

Fix sources encoding to UTF-8 ----------------------------- Key: JBREM-1286 URL: https://issues.jboss.org/browse/JBREM-1286 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ondrej Zizka Compiling 395 source files to build/classes src/main/org/jboss/remoting/callback/CallbackStore.java:79: unmappable character for encoding UTF-8 * Key for setting the file suffix to use for the callback objects written to disk. The default value is �ser�. src/main/org/jboss/remoting/callback/CallbackStore.java:79: unmappable character for encoding UTF-8 * Key for setting the file suffix to use for the callback objects written to disk. The default value is �ser�. 2 errors -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

6
9
0 / 0

[JBoss JIRA] Created: (JBREM-1169) Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold

by mingjun jiang (JIRA)

Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-1169 URL: https://jira.jboss.org/jira/browse/JBREM-1169 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: detection Affects Versions: 2.2.3.SP1 Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1 Reporter: mingjun jiang We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging Configuration: We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean. How to reproduce this issue: 1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10 2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10. 3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20 4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side 2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at java.io.FilterInputStream.read(FilterInputStream.java:66) at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

4
5
0 / 0

[JBoss JIRA] Created: (JBREM-1054) Annotation to automatically return new transporters types

by David Lloyd (JIRA)

Annotation to automatically return new transporters types --------------------------------------------------------- Key: JBREM-1054 URL: https://jira.jboss.org/jira/browse/JBREM-1054 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Priority: Optional Fix For: 3.1.0.Beta1 It would be cool if a transporter interface (or an implementing class of that interface) could have methods which sport an annotation that indicates that the return value of that method, if it is an interface, should be automatically wrapped into a transporter (if invoked via a transporter). This way, complex remote object structures can be easily created and used. Also handy would be a simple way of notating such methods when the interface and implementation are already existent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
14
0 / 0

[JBoss JIRA] Created: (JBREM-1287) getting java.lang.RuntimeException: Unreachable?: Service unavailable. after reaching around 100 odd remote connections

by Dinuka Arseculeratne (JIRA)

getting java.lang.RuntimeException: Unreachable?: Service unavailable. after reaching around 100 odd remote connections ----------------------------------------------------------------------------------------------------------------------- Key: JBREM-1287 URL: https://issues.jboss.org/browse/JBREM-1287 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Environment: Redhat Linux Reporter: Dinuka Arseculeratne Priority: Critical i am getting java.lang.RuntimeException: Unreachable?: Service unavailable. error within my jbos 4.2.3 app server when doing a load test. During the test when we reach around 100+ remote ejb lookup calls we get this error. It works fine for any connections around 70. After this error comes we have to restart the servers. Our architecture is such that we have the web and app servers separated and remote calls happen between the two servers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1264) Release 2.2.3.SP4

by Ron Sigal (JIRA)

Release 2.2.3.SP4 ----------------- Key: JBREM-1264 URL: https://issues.jboss.org/browse/JBREM-1264 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP4 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1283) CLONE [JBREM-1281] - Support setting executor in CoyoteInvoker

by Ron Sigal (JIRA)

CLONE [JBREM-1281] - Support setting executor in CoyoteInvoker -------------------------------------------------------------- Key: JBREM-1283 URL: https://issues.jboss.org/browse/JBREM-1283 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.4 Reporter: Justin Bertram Assignee: Ron Sigal Fix For: 2.2.4.SP1 In Tomcat 5.5 org.apache.coyote.http11.Http11Protocol [1] inherited its getters and setters from org.apache.coyote.http11.Http11BaseProtocol [2] and one could set "minSpareThreads" and "maxSpareThreads" directly. However, in Tomcat 6.0 [3] there is a new setExecutor method which takes a java.util.concurrent.Executor (i.e. not a String or a primitive like the other setters). The org.jboss.remoting.transport.coyote.CoyoteInvoker.setProperty(..) method doesn't support this. [1] http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/coyo... [2] http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/coyo... [3] http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/coyote/http11/Http... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-1282) ServerInvoker does not close StreamHandler in the case of "addstreamcallback"

by Ramesh Reddy (JIRA)

ServerInvoker does not close StreamHandler in the case of "addstreamcallback" ----------------------------------------------------------------------------- Key: JBREM-1282 URL: https://issues.jboss.org/browse/JBREM-1282 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.1 (Flounder) Reporter: Ramesh Reddy Attachments: JBossRemoting.patch This started out http://community.jboss.org/thread/163742 and in Teiid project we created a JIRA for this https://issues.jboss.org/browse/TEIID-1511 while debugging for this issue, I found that in ServerInvoker, for "AddStreamCallback" block in the "handleInternalInvocation" method it does not close the stream handler once it is done. This results in open socket connection. I am not sure if this connection closes after some idle time, but in our case user is rapidly going through deploy and undeploy action, results in too many open files. I created a patch and tested with our usecase, the problem no longer exists. Please find attached patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
15
0 / 0

[JBoss JIRA] Created: (JBREM-1288) StreamServer for in-jvm connection should create a LocalServerInvoker

by Ron Sigal (JIRA)

StreamServer for in-jvm connection should create a LocalServerInvoker --------------------------------------------------------------------- Key: JBREM-1288 URL: https://issues.jboss.org/browse/JBREM-1288 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.4.SP1, 2.2.4 Reporter: Ron Sigal Fix For: 2.2.4.SP1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues April 2011