June 2012 - jboss-remoting-issues

[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-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] (JBREM-1308) MicroSocketClientInvoker hangs on SocketInputStream.read causing deadlock in MessageSucker.setConsuming

by Giovanni Pelosi (JIRA)

Giovanni Pelosi created JBREM-1308: -------------------------------------- Summary: MicroSocketClientInvoker hangs on SocketInputStream.read causing deadlock in MessageSucker.setConsuming Key: JBREM-1308 URL: https://issues.jboss.org/browse/JBREM-1308 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.4 Environment: jboss-4.2.3.GA with jboss-messaging-1.4.5.GA and latest jboss-remoting-2_2_4, 3 node cluster, jms clustered queues Reporter: Giovanni Pelosi In production enviroment, our jboss line of 3 clustered servers randomly (once a week) seemes to hang, refusing to reply to remote jms clients. Taking stack trace of all jboss instances (jstack) we always see the same pattern of deadlock: A non-pooled thread, started internally by remoting, is trying to recover a "connectionExeption" condition (ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:120)), but the task hangs (without timeout) on a socket read: (MicroSocketClientInvoker.readVersion(MicroSocketClientInvoker.java:1077)) This non-terminating network operation holds a lock, acquired in MessageSucker.suspend(MessageSucker.java:225) that in turns cause deadlock in messaging layer: org.jboss.messaging.core.impl.MessagingQueue.informSuckers(MessagingQueue.java:566) causing blocks in all jms traffic. Offending thread stack: ------------------------------------------------- "Thread-5163" daemon prio=10 tid=0x00007f1bc4d10800 nid=0x2b70 runnable [0x00007f1af61e0000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:146) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read(BufferedInputStream.java:254) - locked <0x00000006d23445f8> (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:83) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.readVersion(MicroSocketClientInvoker.java:1077) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:682) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:458) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:141) at org.jboss.remoting.Client.invoke(Client.java:1925) at org.jboss.remoting.Client.invoke(Client.java:786) at org.jboss.remoting.Client.invoke(Client.java:774) at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189) at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160) at org.jboss.jms.client.delegate.ClientConsumerDelegate.org$jboss$jms$client$delegate$ClientConsumerDelegate$close$aop(ClientConsumerDelegate.java:122) at org.jboss.jms.client.delegate.ClientConsumerDelegate$close_N4742752445160157748.invokeNext(ClientConsumerDelegate$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.ClientConsumerDelegate$close_N4742752445160157748.invokeNext(ClientConsumerDelegate$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.ClientConsumerDelegate$close_N4742752445160157748.invokeNext(ClientConsumerDelegate$close_N4742752445160157748.java) at org.jboss.jms.client.delegate.ClientConsumerDelegate.close(ClientConsumerDelegate.java) at org.jboss.messaging.core.impl.clusterconnection.MessageSucker.suspend(MessageSucker.java:225) - locked <0x0000000605960788> (a org.jboss.messaging.core.impl.clusterconnection.MessageSucker) at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager$ConnectionInfo.cleanupConnection(ClusterConnectionManager.java:804) - locked <0x0000000605960ca8> (a org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager$ConnectionInfo) at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager$ConnectionInfo.onException(ClusterConnectionManager.java:785) at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:120) at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:498) ------------------------------------------------- JMS Layer main lock ------------------------------------------------- "Thread-5167" daemon prio=10 tid=0x00007f1be0069800 nid=0x2b82 waiting for monitor entry [0x00007f1afac2b000] java.lang.Thread.State: BLOCKED (on object monitor) at org.jboss.messaging.core.impl.clusterconnection.MessageSucker.setConsuming(MessageSucker.java:288) - waiting to lock <0x0000000605960788> (a org.jboss.messaging.core.impl.clusterconnection.MessageSucker) at org.jboss.messaging.core.impl.MessagingQueue.informSuckers(MessagingQueue.java:566) at org.jboss.messaging.core.impl.MessagingQueue.deliverInternal(MessagingQueue.java:516) at org.jboss.messaging.core.impl.ChannelSupport.deliver(ChannelSupport.java:375) - locked <0x00000006012cdd50> (a java.lang.Object) at org.jboss.jms.server.endpoint.ServerSessionEndpoint$2.run(ServerSessionEndpoint.java:1574) at org.jboss.messaging.util.OrderedExecutorFactory$ChildExecutor.run(OrderedExecutorFactory.java:120) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) ------------------------------------------------- Sample of deadlocked JMS Client Thread: ------------------------------------------- "WorkManager(2)-42959" daemon prio=10 tid=0x00007f1bb806c000 nid=0x2b6c waiting for monitor entry [0x00007f1adf230000] java.lang.Thread.State: BLOCKED (on object monitor) at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:242) - waiting to lock <0x00000006012cdd50> (a java.lang.Object) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2345) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:515) at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:769) at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:399) at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87) at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java) at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157) at sun.reflect.GeneratedMethodAccessor153.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121) at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java) at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java) at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95) at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:862) at org.jboss.remoting.ServerInvoker$1.run(ServerInvoker.java:1901) at org.jboss.jms.server.remoting.DirectThreadPool.run(DirectThreadPool.java:63) at org.jboss.remoting.ServerInvoker.handleOnewayInvocation(ServerInvoker.java:1912) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:832) at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101) at org.jboss.remoting.Client.invoke(Client.java:1925) at org.jboss.remoting.Client.invoke(Client.java:786) at org.jboss.remoting.Client.invokeOneway(Client.java:837) at org.jboss.remoting.Client.invokeOneway(Client.java:1023) at org.jboss.remoting.Client.invokeOneway(Client.java:1014) at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:180) at org.jboss.jms.client.delegate.DelegateSupport.doInvokeOneway(DelegateSupport.java:165) at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$send$aop(ClientSessionDelegate.java:495) at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java) at org.jboss.jms.client.container.SessionAspect.handleSend(SessionAspect.java:661) at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect28.invoke(SessionAspect28.java) at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.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.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.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.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java) at org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java) at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:276) at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect39.invoke(ProducerAspect39.java) at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.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.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java) at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java) at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:165) at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:208) at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:146) at com.pirelli.pmp.jms.JmsClient.send(JmsClient.java:457) at com.pirelli.pmp.jms.JmsClient.send(JmsClient.java:606) at com.pirelli.pmp.jms.JmsClient.send(JmsClient.java:655) at com.pirelli.pmp.jms.GuiResponseQueueHelper.sendReplyMessage(GuiResponseQueueHelper.java:31) at com.pirelli.pmp.jms.GuiResponseQueueHelper.sendReplyMessage(GuiResponseQueueHelper.java:26) at com.pirelli.pmp.mdb.ActivityStarterMdb.replyToGUI(ActivityStarterMdb.java:153) at com.pirelli.pmp.mdb.ActivityStarterMdb.onMessage(ActivityStarterMdb.java:95) at sun.reflect.GeneratedMethodAccessor1335.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112) at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166) at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126) at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:249) at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:268) at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:138) at $Proxy117.onMessage(Unknown Source) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178) at org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160) at org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831) at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect14.invoke(SessionAspect14.java) at org.jboss.jms.client.delegate.ClientSessionDelegate$run_N8003352271541955702.invokeNext(ClientSessionDelegate$run_N8003352271541955702.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.ClientSessionDelegate$run_N8003352271541955702.invokeNext(ClientSessionDelegate$run_N8003352271541955702.java) at org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java) at org.jboss.jms.client.JBossSession.run(JBossSession.java:199) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:237) at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204) at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:761) at java.lang.Thread.run(Thread.java:679) ------------------------------------------- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
7
0 / 0

[JBoss JIRA] (JBREM-1305) Maximum number of client sockets in MicroSocketClientInvoker increases after timeout waiting for a free socket

by Torsten Neise (JIRA)

Torsten Neise created JBREM-1305: ------------------------------------ Summary: Maximum number of client sockets in MicroSocketClientInvoker increases after timeout waiting for a free socket Key: JBREM-1305 URL: https://issues.jboss.org/browse/JBREM-1305 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.5.4.SP3, 2.2.4, 2.5.2.SP3 (Flounder), 2.5.0.SP2 (Flounder) , 2.4.0.SP1 (Pinto) Environment: all Reporter: Torsten Neise Maximum number of client sockets in MicroSocketClientInvoker increases after timeout waiting for a free socket. This happens because of an illegal call of semaphore.release() in MicroSocketClientInvoker.transport(...) after semaphore.attempt(timeToWait) returned with false (no lock aquired) in MicroSocketClientInvoker.getConnection(...). public class MicroSocketClientInvoker extends RemoteClientInvoker { ... protected Object transport(String sessionID, Object invocation, Map metadata, Marshaller marshaller, UnMarshaller unmarshaller) throws IOException, ConnectionFailedException, ClassNotFoundException { ... try { socketWrapper = getConnection(marshaller, unmarshaller, timeLeft); } ... catch (Exception e) { // if (bailOut) // return null; semaphore.release(); ... } ... } protected SocketWrapper getConnection(Marshaller marshaller, UnMarshaller unmarshaller, int timeAllowed) throws Exception { long start = System.currentTimeMillis(); long timeToWait = (timeAllowed > 0) ? timeAllowed : 30000; boolean timedout = !semaphore.attempt(timeToWait); if (trace) log.trace(this + " obtained semaphore: " + semaphore.permits()); if (timedout) { throw new IllegalStateException("Timeout waiting for a free socket"); } ... } ... } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
4
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

12 years, 5 months

4
5
0 / 0

[JBoss JIRA] (JBREM-1311) Incorret link in 'Building Remoting from source' page

by Rostislav Svoboda (JIRA)

12 years, 5 months

2
4
0 / 0

[JBoss JIRA] (JBREM-1307) TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks

by Doug Grove (JIRA)

Doug Grove created JBREM-1307: --------------------------------- Summary: TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks Key: JBREM-1307 URL: https://issues.jboss.org/browse/JBREM-1307 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.3.SP2 Environment: JBoss EAP 4.3.0 CP08 and CP10 Reporter: Doug Grove In order to provide a mechanism for timing out a network/socket write operation, the org.jboss.remoting.transport.socket.TimedOutputStream class starts a timer. If the duration of the write operation exceeds the timer interval, then the timer will call close() on the output stream. This interrupts the output stream write() operation and causes the write operation to throw an IOException. When the output stream uses secure sockets (SSL), however, the call to close() on the output stream can block indefinitely. The threads associated with the write() and close() operation will only clear when the tcp keepalive timeout mechanism in the operation system is invoked. This appears to be related to a know bug in the java runtime: http://bugs.sun.com/view_bug.do?bug_id=6358629 Specifically, in a thread dump you will see: "Timer-9" daemon prio=10 tid=0x5016c400 nid=0x2638 waiting on condition [0x4cbad000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x585021a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1720) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1564) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1362) - locked <0x58502030> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1301) at com.sun.net.ssl.internal.ssl.AppOutputStream.close(AppOutputStream.java:80) at org.jboss.remoting.transport.socket.TimedOutputStream.close(TimedOutputStream.java:57) at org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask.run(TimedOutputStream.java:145) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
4
0 / 0

[JBoss JIRA] (JBREM-1302) Can't invoke remote object if server bind address is 0.0.0.0

by Sergey Chernov (Created) (JIRA)

Can't invoke remote object if server bind address is 0.0.0.0 ------------------------------------------------------------ Key: JBREM-1302 URL: https://issues.jboss.org/browse/JBREM-1302 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.5.4.SP2 Environment: Jboss 5.1.0 jdk 1.6 jboss remoting 2.5.4.SP2 Reporter: Sergey Chernov When jboss bind address is set to `0.0.0.0` remote client gets exception while trying to invoke remote object's method: java.rmi.ConnectException: Connection refused to host: lx4-schernov.nn.five9.com; nested exception is: java.net.ConnectException: Connection refused: connect at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110) at org.jboss.remoting.transport.rmi.RMIServerInvoker_Stub.transport(Unknown Source) at org.jboss.remoting.transport.rmi.RMIClientInvoker.callTransport(RMIClientInvoker.java:648) at org.jboss.remoting.transport.rmi.RMIClientInvoker.access$100(RMIClientInvoker.java:78) at org.jboss.remoting.transport.rmi.RMIClientInvoker$1.run(RMIClientInvoker.java:402) at org.jboss.util.threadpool.RunnableTaskWrapper.run(RunnableTaskWrapper.java:147) at org.jboss.util.threadpool.BasicThreadPool.executeOnThread(BasicThreadPool.java:473) at org.jboss.util.threadpool.BasicThreadPool.runTaskWrapper(BasicThreadPool.java:201) at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:420) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:169) at org.jboss.remoting.Client.invoke(Client.java:2070) at org.jboss.remoting.Client.invoke(Client.java:879) at org.jboss.remoting.Client.invoke(Client.java:867) at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:479) at $Proxy0.getMySumHost(Unknown Source) at test.Main.main(Main.java:45) Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:193) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:525) at java.net.Socket.connect(Socket.java:475) at java.net.Socket.<init>(Socket.java:372) at java.net.Socket.<init>(Socket.java:186) at javax.net.DefaultSocketFactory.createSocket(SocketFactory.java:206) at org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory.createSocketPrivate(RemotingRMIClientSocketFactory.java:333) at org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory.createSocket(RemotingRMIClientSocketFactory.java:210) at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595) ... 18 more It happens because RemotingRMIClientSocketFactory had been created with wrong ('0.0.0.0') host name which becomes effective host while creating socket: log: 328 [main] TRACE org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory - host: lx4-schernov.nn.five9.com, effective host: 0.0.0.0, port: 47952 source: public Socket createSocket(String host, final int port) throws IOException 176 { ... 181 final String effectiveHost = hostName != null ? hostName : host; While creating factory it should be checked, that host name is not broadcast or localhost address, to make client's locatorUri mandatory for such cases. Client source code: String address = "remote.host.com"; Properties props = new Properties(); props.put(InitialContext.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); props.put(InitialContext.PROVIDER_URL, "jnp://" + address + ":1099"); props.put(InitialContext.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces"); InitialContext context = new InitialContext(props); Object tmp = context.lookup("remote/subsystem/Object"); ObjectInf object = (ObjectInf) tmp; object.doJob(); // here exception it thrown -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

5
5
0 / 0

[JBoss JIRA] (JBREM-1310) Remoting testsuite has hard-coded IPv6 addresses making it less portable

by Radoslav Husar (JIRA)

Radoslav Husar created JBREM-1310: ------------------------------------- Summary: Remoting testsuite has hard-coded IPv6 addresses making it less portable Key: JBREM-1310 URL: https://issues.jboss.org/browse/JBREM-1310 Project: JBoss Remoting Issue Type: Quality Risk Security Level: Public (Everyone can see) Components: general Reporter: Radoslav Husar Remoting testsuite has hard-coded IPv6 addresses making it less portable and this is not cool because we are using the testsuite for platform certification. Not all machines have properly configured (or support) IPv6 stack. In either way, the TS should be able to test both stacks. I suggest to use common alias "localhost" and only control via -DpreferXY to select IPv4 or 6 stack. AFAIR the systems have alias localhost for both addresses. Let me know if there is an issue with this approach (will attach commit/ pull request). {noformat} [rhusar@rhusar jboss-remoting]$ cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1309) Remoting testsuite hangs in ConnectionCloseTestCase, ConnectionTestCase

by Radoslav Husar (JIRA)

Radoslav Husar created JBREM-1309: ------------------------------------- Summary: Remoting testsuite hangs in ConnectionCloseTestCase, ConnectionTestCase Key: JBREM-1309 URL: https://issues.jboss.org/browse/JBREM-1309 Project: JBoss Remoting Issue Type: Quality Risk Security Level: Public (Everyone can see) Components: general Affects Versions: 2.2.4 Reporter: Radoslav Husar We are running Remoting testsuite as part of platform certification, unfortunately the TS hangs very often. {noformat} ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.jboss.remoting3.test.CloseableTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.191 sec Running org.jboss.remoting3.test.RemoteChannelTest Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.437 sec Running org.jboss.remoting3.test.ConnectionCloseTestCase {noformat} or on windows also on https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Remoting/job/eap-6... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 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 2012