activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <>
Subject [jira] Resolved: (AMQ-2277) NIO SelectorWorker not protecting its Selector from mutable operations
Date Wed, 03 Jun 2009 09:25:50 GMT


Gary Tully resolved AMQ-2277.

    Resolution: Fixed

patch applied in r781312,

> NIO SelectorWorker not protecting its Selector from mutable operations
> ----------------------------------------------------------------------
>                 Key: AMQ-2277
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.2.0
>         Environment: 5.2.x, trunk. Problem seen on Linux and Solaris.
>            Reporter: Dave Stanley
>            Assignee: Gary Tully
>         Attachments: nio_patch.txt
> When you hit the NIO transport with heavy concurrent connection load the brokers thread
usage spikes with lots of threads in the state below.   
> "ActiveMQ Transport Initiator: /" daemon prio=10 tid=0x007a2fc0 nid=0x34b
waiting for monitor entry [0xc4381000..0xc4381888]
>         at org.apache.activemq.transport.nio.SelectorManager.register(
>         - waiting to lock <0xd8b1d920> (a org.apache.activemq.transport.nio.SelectorManager)
>         at org.apache.activemq.transport.nio.NIOTransport.initializeStreams(
>         at org.apache.activemq.transport.tcp.TcpTransport.connect(
>         at org.apache.activemq.transport.nio.NIOTransport.doStart(
>         at org.apache.activemq.util.ServiceSupport.start(    
   at org.apache.activemq.transport.TransportFilter.start(
>         at org.apache.activemq.transport.TransportFilter.start(
>         at org.apache.activemq.transport.WireFormatNegotiator.start(
>         at org.apache.activemq.transport.TransportFilter.start(
>         at
>         - locked <0xdb727578> (a
>         at$1$
> Problem is easily reproducible when consumer/producer are on a different machine to the
broker - when running everything locally .. not so much.
> It seems the SelectorWorker is not tolerant of lots of concurrent updates to the state
of the Selector, and the selector gets into a bad state. 
> Attached patch seems to resolve the issue. Patch adds some locking around when selectorKeys
are registered and canceled.

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

View raw message