June 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

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, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1295) CloseHandlers are not called when the remote connection closes

by Kabir Khan (JIRA)

CloseHandlers are not called when the remote connection closes -------------------------------------------------------------- Key: JBREM-1295 URL: https://issues.jboss.org/browse/JBREM-1295 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Kabir Khan Assignee: David Lloyd THis is for 3.2.0 which does not appear in the version list Adding the following to org.jboss.remoting3.test.ChannelTestBase.java, the close handler does not get called. We discussed on IRC a few days ago but no matter what I do to close the channel this does not get called. Please provide a working example @Test public void testRemoteChannelClose() throws Exception { final CountDownLatch closedLatch = new CountDownLatch(1); sendChannel.addCloseHandler(new CloseHandler<Channel>() { @Override public void handleClose(Channel closed) { closedLatch.countDown(); } }); recvChannel.writeShutdown(); IoUtils.safeClose(recvChannel); System.out.println("Waiting for closed"); closedLatch.await(); System.out.println("Closed"); } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1294) RemoteConnectionHandler leaks connections

by Kabir Khan (JIRA)

RemoteConnectionHandler leaks connections ----------------------------------------- Key: JBREM-1294 URL: https://issues.jboss.org/browse/JBREM-1294 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Kabir Khan Assignee: David Lloyd 3.2.0 is not in the list of versions Nothing ever calls RemoteConnectionHandler.channels.remove -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
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-1291) Release 2.5.4.SP2

by Ron Sigal (JIRA)

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

13 years, 6 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues June 2011