[
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)
