[ https://issues.apache.org/jira/browse/ARTEMIS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322636#comment-16322636 ]
ASF subversion and git services commented on ARTEMIS-1601: ---------------------------------------------------------- Commit b8f591b6b9b84cbea599db95c6b743a2c4088319 in activemq-artemis's branch refs/heads/master from jostbg [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=b8f591b ] ARTEMIS-1601 deal with race in Stomp sendMessage If the Stomp consumer was closed at or near the same time a message was dispatched then an NPE might result. Throwing an exception is a relatively expensive operation in the JVM because of the stacktrace information that needs to be generated, so in cases where it is known that a null value could be returned one should check and handle it appropriately. > NPE silently thrown in StompSession#sendMessage > ----------------------------------------------- > > Key: ARTEMIS-1601 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1601 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: STOMP > Affects Versions: 2.4.0 > Environment: Artemis 2.5.0-SNAPSHOT > Reporter: Johan Stenberg > Assignee: Justin Bertram > Priority: Minor > > During debugging a stomp session I realized that the StompSession's send > method does not check if looking up a subscription returns null: > {code:java} > StompSubscription subscription = subscriptions.get(consumer.getID()); > {code} > This later sometimes results NPEs at: > {code:java} > if (subscription.getAck().equals(Stomp.Headers.Subscribe.AckModeValues.AUTO)) > { > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)