activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-3605) NullPointerException in TransportConnection
Date Wed, 23 Nov 2011 18:29:41 GMT

    [ https://issues.apache.org/jira/browse/AMQ-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13156035#comment-13156035
] 

Timothy Bish commented on AMQ-3605:
-----------------------------------

For the error I was able to reproduce the problem comes from a race between the processDispatch
in TransportConnection's iterate method and the processRemoveConnection method where is does:

{noformat}
 TransportConnectionState state = unregisterConnectionState(id);
{noformat}

Since the connection is removed right before the processDispatch males the loop from the Stomp
transport's auto ack of the dispatched message we end up with the above error.  The NPE that
the reporter has seen is probably related to something similar.  

                
> NullPointerException in TransportConnection
> -------------------------------------------
>
>                 Key: AMQ-3605
>                 URL: https://issues.apache.org/jira/browse/AMQ-3605
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 5.5.0
>         Environment: SLES 11 SP1
> java version "1.6.0_23"
> perl 5.10.0 + Net::Stomp 0.38_99
>            Reporter: Tommy Lindgren
>            Priority: Critical
>              Labels: stomp
>         Attachments: StompDedicatedTaskRunnerTests.java
>
>
> I'm running ActiveMQ 5.5.0 and clients using Net::Stomp 0.38_99 and I'm seeing infrequent
NullPointerExceptions in TransportConnection:
> {noformat}
> Exception in thread "ActiveMQ Connection Dispatcher: /172.31.201.11:50607" java.lang.NullPointerException
>         at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:327)
>         at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179)
>         at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:69)
>         at org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:81)
>         at org.apache.activemq.transport.stomp.StompSubscription.onMessageDispatch(StompSubscription.java:79)
>         at org.apache.activemq.transport.stomp.ProtocolConverter.onActiveMQCommand(ProtocolConverter.java:596)
>         at org.apache.activemq.transport.stomp.StompTransportFilter.oneway(StompTransportFilter.java:58)
>         at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
>         at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1270)
>         at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:815)
>         at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:851)
>         at org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:104)
>         at org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:42)
> {noformat}
> This seems to happen 1-2 times per month or so but the result is dire: new messages aren't
delivered to the affected client (you can see the number of pending messages increasing in
the admin web interface) until the client or ActiveMQ is restarted.
> Relevant code snippet from TransportConnection.java,
> {noformat}
> 326         if (context != null) {
> 327             if (context.isDontSendReponse()) {
> {noformat}
> implies that we are dealing with a race condition. I'm not familiar with the ActiveMQ
code base but it looks like it grabs a lock (serviceLock) before entering that function, so
not sure what's going on.
> Since there's no timestamp associated with the stack trace I'm not completly sure what's
going on on the client side. I've tried to reproduce it by writing a small script that uses
Net::Stomp in a similar way to my real clients, but no luck so far.
> No idea if it's relevant, but my affected clients have been both consuming and producing,
and sending/receiving on both topics and queues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message