September 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

11 years, 9 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

11 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1301) WebUtil.isBinary fails when charSet appended

by Tom Cunningham (JIRA)

WebUtil.isBinary fails when charSet appended -------------------------------------------- Key: JBREM-1301 URL: https://issues.jboss.org/browse/JBREM-1301 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: jmx remoting, marshall Affects Versions: 2.5.4.SP2 Reporter: Tom Cunningham WebUtil.isBinary fails when the contentType equals application/octet-stream?charSet=UTF-8 It only accepts "application/octet-stream" as valid. On 1.6.0_21, I'm receiving "application/octet-stream?charSet=UTF-8" as my ContentType from HttpUrlConnection.getHeaderFields() within HttpClientInvoker, which overwrites any ContentType I try to send in a map. Because of this, my responses are InvocationResponses, but they are treated as a string and not unmarshalled. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

4
5
0 / 0

[JBoss JIRA] Created: (JBREM-1298) Release 2.5.4.SP3

by Ron Sigal (JIRA)

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

12 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1297) Deadlock between MicroRemoteClientInvoker.establishLease and Client.notifyListeners

by Artur Karpinski (JIRA)

Deadlock between MicroRemoteClientInvoker.establishLease and Client.notifyListeners ----------------------------------------------------------------------------------- Key: JBREM-1297 URL: https://issues.jboss.org/browse/JBREM-1297 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.4.SP2 Reporter: Artur Karpinski Priority: Critical Deadlock is probably caused by changes introduced in this fix: JBREM-1242. Thread A: 1. MicroRemoteClientInvoker.terminateLease, locks clientLeaseLock 2. Client.notifyListeners, locks connectionValidatorLock Thread B: 1. Client.setupClientLease, locks connectionValidatorLock 2. MicroRemoteClientInvoker.establishLease, locks connectionValidatorLock Please check stacktraces when this deadlock occurred: {code} "Timer-16" - Thread t@486453 java.lang.Thread.State: BLOCKED at org.jboss.remoting.Client.notifyListeners(Client.java:1873) - waiting to lock <747c39d3> (a java.lang.Object) owned by "WorkManager(2)-241" t@6121 at org.jboss.remoting.LeasePinger.stopPing(LeasePinger.java:134) at org.jboss.remoting.MicroRemoteClientInvoker.terminateLease(MicroRemoteClientInvoker.java:434) - locked <751714e> (a java.lang.Object) at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:1081) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) {code} and {code} "WorkManager(2)-241" - Thread t@6121 java.lang.Thread.State: BLOCKED at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:507) - waiting to lock <751714e> (a java.lang.Object) owned by "Timer-16" t@486453 at org.jboss.remoting.Client.setupClientLease(Client.java:2056) - locked <747c39d3> (a java.lang.Object) at org.jboss.remoting.Client.connect(Client.java:1918) at org.jboss.remoting.Client.connect(Client.java:737) {code} One way to fix this would be to add lock on connectionValidatorLock in MicroRemoteClientInvoker.terminateLease. I'm trying to analyse code to check if this fix will not introduce another deadlock problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

5
11
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

12 years, 4 months

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

12 years, 5 months

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

12 years, 5 months

3
14
0 / 0

[JBoss JIRA] Commented: (JBREM-942) A deadlock encountered on ConnectionValidator

by Mayank Mittal (JIRA)

[ https://issues.jboss.org/browse/JBREM-942?page=com.atlassian.jira.plugin.... ] Mayank Mittal commented on JBREM-942: ------------------------------------- I'm facing the same issue with AS : JBoss 4.2.3 GA Remoting: 2.4.0 SP1 whenever during the fail-over I perform any operation. I'm using HA-JNDI (1100) to make connections to my server. As it is expected from the HA system, that fail-over should be transparent from user point of view. here is the stack "Thread-113" daemon prio=10 tid=0x00007f53243ea000 nid=0x57e5 waiting for monitor entry [0x00007f5322829000] java.lang.Thread.State: BLOCKED (on object monitor) at org.jboss.remoting.ConnectionValidator.removeConnectionListener(ConnectionValidator.java:359) - waiting to lock <0x00000000c7b93480> (a java.lang.Object) at org.jboss.remoting.Client.removeConnectionListener(Client.java:445) at org.jboss.jms.client.remoting.JMSRemotingConnection.removeConnectionListener(JMSRemotingConnection.java:533) - locked <0x00000000c7b27a08> (a org.jboss.jms.client.remoting.JMSRemotingConnection) at org.jboss.jms.client.container.ConnectionAspect.handleClose(ConnectionAspect.java:185) 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:597) at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121) at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java) at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:179) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java) at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java) at org.jboss.jms.client.JBossConnection.close(JBossConnection.java:132) at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager$ConnectionInfo$1.call(ClusterConnectionManager.java:705) at EDU.oswego.cs.dl.util.concurrent.FutureResult$1.run(FutureResult.java:75) at java.lang.Thread.run(Thread.java:662) "Timer-22" daemon prio=10 tid=0x0000000041cfd800 nid=0x5264 waiting for monitor entry [0x00007f5323234000] java.lang.Thread.State: BLOCKED (on object monitor) at org.jboss.remoting.ConnectionValidator.notifyListeners(ConnectionValidator.java:600) - waiting to lock <0x00000000c7b93480> (a java.lang.Object) at org.jboss.remoting.ConnectionValidator.access$600(ConnectionValidator.java:42) at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:648) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) > A deadlock encountered on ConnectionValidator > ---------------------------------------------- > > Key: JBREM-942 > URL: https://issues.jboss.org/browse/JBREM-942 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transport > Affects Versions: 2.2.2.SP5 > Environment: JBoss-EAP-4.2, JBossMessaging-1.4.0-SP3, JBossRemoting-2.2.2-SP5 > Reporter: Tyronne Wickramarathne > Assignee: Ron Sigal > Priority: Critical > Fix For: 2.2.2.SP7 > > > This deadlock occurred on JBREM when a JBossMessaging Bridge was set and consuming messages. here's the StackTrace : > Found one Java-level deadlock: > ============================= > "Thread-278": > waiting to lock monitor 0x08128544 (object 0xce8b25e0, a java.lang.Object), > which is held by "Timer-4" > "Timer-4": > waiting to lock monitor 0x08129160 (object 0xce89f508, a java.util.ArrayList), > which is held by "Thread-278" > Java stack information for the threads listed above: > =================================================== > "Thread-278": > at org.jboss.remoting.ConnectionValidator.doStop(ConnectionValidator.java:526) > - waiting to lock <0xce8b25e0> (a java.lang.Object) > at org.jboss.remoting.ConnectionValidator.stop(ConnectionValidator.java:252) > at org.jboss.remoting.ConnectionValidator.removeConnectionListener(ConnectionValidator.java:344) > - locked <0xce89f508> (a java.util.ArrayList) > at org.jboss.remoting.Client.removeConnectionListener(Client.java:398) > at org.jboss.jms.client.remoting.JMSRemotingConnection.removeConnectionListener(JMSRemotingConnection.java:493) > - locked <0xce8b18c8> (a org.jboss.jms.client.remoting.JMSRemotingConnection) > at org.jboss.jms.client.container.ConnectionAspect.handleClose(ConnectionAspect.java:184) > at sun.reflect.GeneratedMethodAccessor134.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121) > at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java) > at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92) > at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) > at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java) > at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170) > at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) > at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java) > at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java) > at org.jboss.jms.client.JBossConnection.close(JBossConnection.java:132) > at org.jboss.jms.server.bridge.Bridge.cleanup(Bridge.java:1098) > at org.jboss.jms.server.bridge.Bridge.access$1100(Bridge.java:66) > at org.jboss.jms.server.bridge.Bridge$FailureHandler.run(Bridge.java:1496) > at java.lang.Thread.run(Thread.java:619) > "Timer-4": > at org.jboss.remoting.ConnectionValidator.notifyListeners(ConnectionValidator.java:553) > - waiting to lock <0xce89f508> (a java.util.ArrayList) > at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:286) > - locked <0xce8b25e0> (a java.lang.Object) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > Found 1 deadlock. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues September 2011