Messaging blocked by long time-out again

[lanceliao1]

I faced the serious problem which messaging blocked by long time-out.It happens often in stressful conditions.
The issue has been discussed in the following link.
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=152037
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222257#4222257

I thinks it's a really serious problem in jboss messaging or remoting. ActiveMQ has the similar issue but it has been resolved.
http://issues.apache.org/activemq/browse/AMQ-1993

[gaohoward]

I'll investigate, thanks.

[timfox]

There's already an old JIRA for this somewhere

[lanceliao1]

I thought there is a issue about remoting callbacktimout setting.The param setting Socket's reading timeout.
But this problem is about Socket's writing timeout.JBM may blocked in socket writing for 10 min in solairs.

[timfox]

1) You need to say what version of JBM and JBR you are using. Please *always* state the version when making a post.

2) Please provide your remoting configuration.

3) Have you looked in JIRA? There have been many remoting timeout issues in the past, all of which, to our knowledge are fixed. E.g. https://jira.jboss.org/jira/browse/JBMESSAGING-1220

[thammoud]

Tim,

We are trying to avoid cross posting as this is really a remoting issue that can be tracked here.

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222257#4222257

[lanceliao1]

We are using Jboss4.2.4 with JBM 1.4.2.GA-SP1 and jboss-remoting-2.2.2.SP11.jar.

 <invoker transport="bisocket">
 <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
 <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
 <attribute name="dataType" isParam="true">jms</attribute>
 <attribute name="socket.check_connection" isParam="true">false</attribute>
 <attribute name="timeout" isParam="true">0</attribute>
 <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
 <attribute name="serverBindPort">4557</attribute>
 <attribute name="clientSocketClass" isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper</attribute>
 <attribute name="serverSocketClass">org.jboss.jms.server.remoting.ServerSocketWrapper</attribute>
 <attribute name="numberOfCallRetries" isParam="true">1</attribute>
 <attribute name="pingFrequency" isParam="true">214748364</attribute>
 <attribute name="pingWindowFactor" isParam="true">10</attribute>
 <attribute name="onewayThreadPool">org.jboss.jms.server.remoting.DirectThreadPool</attribute>

 <attribute name="clientLeasePeriod" isParam="true">10000</attribute>
 <attribute name="numberOfRetries" isParam="true">10</attribute>
 <attribute name="JBM_clientMaxPoolSize" isParam="true">200</attribute>
 <!-- The maximum time to wait before timing out on trying to write a message to socket for delivery -->
 <attribute name="callbackTimeout">10000</attribute>
 </invoker>

The remoting guys resolve the problem by setting TCP TTL.This is a ugly way.

[timfox]

"lanceliao1" wrote:

The remoting guys resolve the problem by setting TCP TTL.This is a ugly way.

JBM 1.x uses JBoss Remoting 2.x, all the transport stuff is handled by JBR so it's up to the JBR team to fix issues related to tha.

FWIW JBM 2.0 does not use JBoss Remoting at all, it uses Netty.

[thammoud]

Tim,

Do we know if the new network library handles this particular issue better than JBOSS remoting? How far along is 2.0? From the website, it is still Alpha.

Thanks.

[timfox]

JBM 2.0 beta will be out in a few weeks.

JBM 2.0 does not use JBoss Remoting due to a long string of issues we have had with it. Instead it has a fully pluggable transport system, and by default uses Netty, Trustin Lee's NIO transport.

By default this is non blocking, so this should be a non issue in JBM 2.0.

[peterj]

Will JBM 2.0 be part of JBoss AS 5.1.0?