<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael,<div>Thank you for pointing this out. In reproducing your results I noticed that I get an error when UNSUBSCRIBE is issued. So that explains why you were still seeing the messages after issuing the UNSUBSCRIBE.</div><div><br></div><div>Before a session can cancel a subscription it needs to know about it -- that is what the id is for.</div><div><br></div><div>The STOMP 1.1 specification says this about subscription ids:</div><div><h4 id="SUBSCRIBE_id_Header" style="font-family: 'Graublau Web', Helvetica, sans-serif; overflow-x: visible; overflow-y: visible; color: rgb(153, 51, 51); ">SUBSCRIBE id Header</h4><p style="margin-bottom: 0px; color: rgb(102, 102, 102); font-family: Georgia, Arial, sans-serif; ">An <code style="font-size: 0.9em; font-family: 'Droid Sans Mono', 'Courier New', monospace !important; ">id</code> header MUST be included in the frame to uniquely identify the subscription within the STOMP connection session. Since a single connection can have multiple open subscriptions with a server, the <code style="font-size: 0.9em; font-family: 'Droid Sans Mono', 'Courier New', monospace !important; ">id</code> header allows the client and server to relate subsequent <code style="font-size: 0.9em; font-family: 'Droid Sans Mono', 'Courier New', monospace !important; ">ACK</code>, <code style="font-size: 0.9em; font-family: 'Droid Sans Mono', 'Courier New', monospace !important; ">NACK</code> or <code style="font-size: 0.9em; font-family: 'Droid Sans Mono', 'Courier New', monospace !important; ">UNSUBSCRIBE</code>frames to the original subscription.</p></div><div><br></div><div>and the phrase "uniquely identify the subscription within the STOMP connection session" is the problem. That implies that the id is *limited in scope* to the session.</div><div><br></div><div>In the case of durable subscriptions, as soon as you disconnect your subscription id is no longer in scope. Reconnecting and using the same id ought to give you a distinct session and therefore a distinct subscription. But then, what good is a durable subscription if you can never refer to it again??</div><div><br></div><div>The solution as adopted in the RabbitMQ STOMP adapter is to make the id on the subscription non-local. That is, we make it global to the RabbitMQ server. (Actually, as implied in the RabbitMQ/stomp documentation, we make the *combination of subscription id and (topic) destination* global to the server.) This means that SUBSCRIBE is the way to reconnect to the same subscription-id x topic, and then you can UNSUBSCRIBE from it (and delete it) successfully.</div><div><br></div><div>[Notice what this means: the messages that were sitting "in the topic" for that subscription id are never discarded completely: in order to remove them you must SUBSCRIBE first -- and they are then delivered to you of course. This is quite a nice 'feature', IMO.]</div><div><br></div><div>I think you might have been aware of this, since you used the header "client-id" on your CONNECT frames. This is not a STOMP header, but might be an ActiveMQ one. It is not clear to me what the full effect of this header is, but it appears to identify a session context for subscription ids (at least). I notice that when the "durable client" reconnected, the subscriptions were not re-instated (no messages arrived) -- is that what you would expect ActiveMQ to do?</div><div><br></div><div>I will raise a bug (we will probably try to behave compatibly with ActiveMQ), and take this up with the STOMP spec group.<br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><div><font class="Apple-style-span" face="Georgia"><br class="Apple-interchange-newline">Steve Powell</font></div><div><font class="Apple-style-span" face="Georgia"><i><a href="mailto:steve@rabbitmq.com">steve@rabbitmq.com</a></i></font></div></div><div><div><div><font class="Apple-style-span" face="Georgia" size="2"><span class="Apple-style-span" style="font-size: 10px; ">[</span><i>wrk</i><span class="Apple-style-span" style="font-size: 10px; ">: +44-2380-111-528] [</span><i>mob</i><span class="Apple-style-span" style="font-size: 10px; ">: +44-7815-838-558]</span></font></div><div style="font-size: 12px; "><font class="Apple-style-span" face="arial" size="3"><span class="Apple-style-span" style="border-collapse: collapse; font-size: 13px; "><i></i></span><i></i></font></div></div></div></span>
</div>
<br><div><div>On 6 Sep 2011, at 19:28, Michael Justin wrote:</div><blockquote type="cite"><a href="http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-September/014915.html">http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-September/014915.html</a></blockquote></div><br></div></body></html>