My concern is what if you had multiple consumers on the same subscription. It seems it's possible to do that on stomp. The first time you called unsubscribe it would delete the queue (if we did this).
I wonder what Jeff Mesnil and Howard would think about it since they worked a lot on Stomp.
I had a quick look and indeed the code does not look right when unsubscribing a durable subscriber.
When, a client wants to create a durable subscriber, he must pass a (non-standard iirc)
Stomp.Headers.Subscribe.DURABLE_SUBSCRIBER_NAME header. In that case, we create a core queue for it.
When a client wants to unsubscribe the durable subscriber, he should pass the same header so that we can remove its core queue.
I did bit mroe work on this, now I am passing correct subscriber id etc from client. I am also calling deleteQueue in StompSession onUnsubscribe
It looks something like this (I added bindingName):
public boolean unsubscribe(String destination, String id, String bindingName) throws Exception
Iterator<Entry<Long, StompSubscription>> iterator = subscriptions.entrySet().iterator();
Map.Entry<Long, StompSubscription> entry = (Map.Entry<Long, StompSubscription>)iterator.next();
long consumerID = entry.getKey();
StompSubscription sub = entry.getValue();
if (id != null && id.equals(sub.getID()))
This works as expected as long as there are no messages in the queue. If there are messages in the queue, it throws NPE:
Any help here would help.
Following up on this post, had the same issues than Ameya and it's solution was helpful while making a patch on my own upon 2.2.20 release last year. Context : HornetQ production servers delivering a few hundreds msg/secs into Topics, with mixed STOMP / JMS consumers.
STOMP consumers mostly using Net::STOMP::Client Perl module.
Behaviour observed on 2.2.20 release and reproduced on current 2.3.0-CR1 :
- selectors : When using a selector, excluded messages still looks routed in the queue, however not delivered to the client. (Observed from the MessageCount JMX attribute value). Also the selector value also does not appear in the JMX 'Filter' attribute. The latter being minor compared to the heap memory saturation caused by the first.
- unsubscribe : The Queue is not destroyed upon a successful unsubscribe : Incoming messages remains routed, also causing heap memory saturation.
Changed slightly more things from Ameya's patch, and been using this since October without trouble. The patch :
- Assign the selector value to the Queue, not the Consumer on the server side : Selector value can then be seen in the JMX Filter attribute, and excluded messages don't looks routed in the queue.
- Destroy the Queue when the last consumer disconnects. (Tested with multiple consumers and several subscribe/unsubcribe cases before the final "unsubscribe, no more consumers" situation.
Starting to look at 2.3.0-CR1, i ported this patch onto the code base & was wondering if those STOMP features could be considered useful & integrated onto the main release at some point. Can provide diff file in that case.
I think you are right Jeff. (sorry for the late response, I missed it)