activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (AMQ-2308) org.apache.activemq.broker.ft.TransactedTopicMasterSlaveTest test hang on Solaris
Date Mon, 29 Jun 2009 09:24:07 GMT

     [ https://issues.apache.org/activemq/browse/AMQ-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gary Tully reassigned AMQ-2308:
-------------------------------

    Assignee: Gary Tully

> 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
>            Assignee: Gary Tully
>         Attachments: TransactedTopicMasterSlaveTest.patch.txt
>
>
> 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