[ https://issues.apache.org/jira/browse/ARTEMIS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322512#comment-16322512 ]
ASF GitHub Bot commented on ARTEMIS-1601: ----------------------------------------- Github user jbertram commented on the issue: https://github.com/apache/activemq-artemis/pull/1772 IMO, it's less clean because now there are 2 places which are returning 0 in case of an error. In any case, it's really not a big deal. One additional question here...Is this NPE mainly theoretical or is there a specific use-case which triggers it? If the former then I'm even less in favor of merging the PR. If the latter then it would be worth adding a test or maybe just describing the use-case in the commit message. > 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)