activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Jones (JIRA)" <j...@apache.org>
Subject [jira] Created: (AMQ-2308) org.apache.activemq.broker.ft.TransactedTopicMasterSlaveTest test hang on Solaris
Date Fri, 26 Jun 2009 16:20:39 GMT
org.apache.activemq.broker.ft.TransactedTopicMasterSlaveTest test hang on Solaris
---------------------------------------------------------------------------------

                 Key: AMQ-2308
                 URL: https://issues.apache.org/activemq/browse/AMQ-2308
             Project: ActiveMQ
          Issue Type: Bug
          Components: Transport
         Environment: Solaris - jdk15 32 bit - also jdk16 64 bit
            Reporter: Peter Jones


Seeing the TransactedTopicMasterSlaveTest hang when run on Solaris.  After examining jstack
output for the hanging test and discussing with Gary Tully, he had the following suggestion:

{quote}
Hi Peter,
this looks like an example of http://issues.apache.org/activemq/browse/AMQ-1993 but this time
on the client side.
It seems like a write that results in the first reconnect attempt does not terminate but it
should be aborting as there is no listening or reading thread. I guess there is no back log
because the next write is blocked by the transport reconnect mutex. Some combination of low
level tcp retries should be able to be configured at the OS level, and I guess the defaults
should be less than 1 hour so I would expect this test to eventually complete, however, the
OS level timeouts and retries may be contingent on a backlog reaching a minimum and currently
there will be only one outstanding write due the the locking around the reconnect logic. This
being the case, some code needs to implement the timeout.

The solution from http://issues.apache.org/activemq/browse/AMQ-1993 may be a good approach
here. It will timeout a write call.

However the solution is currently only applicable to server side sockets, it needs to be extended
to support a client connection.

I think all that is needed is to move the additional configuration code from:
org.apache.activemq.transport.TransportFactory.serverConfigure(Transport, WireFormat, HashMap)
to compositeConfigure that is called for all transports (both client and server)
{quote}

Indeed, this fixes the problem.  I've attached a patch against trunk which resolves the issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message