unsubscribe on disconnect() and/or __destruct()

[staabm]

shouldn't one of the client classes keep track of all subscriptions and unsubscribe all subscriptions to cleanup server side state?

we assume this is a problem.. we realized that subscriptions don't get cleaned up because see some consumers don't disconnect from the queue point of view... not sure this is our actual problem, but I figured it would be worth noting/discussing.

[jmglsn]

• Are you using the StatefulStomp implementation? There is SubscriptionList in use.
• Are heartbeats configured?
• How are subscriptions are configured? (Because it's possible to configure persistent subscriptions.)
  In general I assume that only with a heartbeat configuration both sides can detect the absence of the partner.

[whikloj]

@staabm doing house-keeping. Is this still an issue you are experiencing or would like to discuss?

[staabm]

we worked arround it on our end. I think it could be still a problem

[whikloj]

Ok, I'm still making my way through the STOMP specification and the code, but I think you were suggesting that on a $client->disconnect(); it would be nice to unsubscribe from all the queues it was subscribed to and then disconnect.

I don't think this is a problem per se, as the server is not even required to deliver any ERROR or RECEIPT frames after it receives a DISCONNECT (https://stomp.github.io/stomp-specification-1.2.html#Connection_Lingering).

But it doesn't mean it wouldn't be a nice feature.

It does appear that the use of a SubscriptionList allows for tracking all the subscriptions. But it doesn't appear to be a way to unsubscribe from them all (tell me if I'm wrong) except maybe something like

while (is_a($client->getState(), 'Stomp\States\ConsumerState')) {
    $client->getState()->unsubscribe();
}

to loop through and unsubscribe from all the subscriptions.

[staabm]

the main point IMO would be to automatically unsubsribe on __destruct(), as we experienced problems in our queue server running out of resources because the php client never unsubscribed.

It does appear that the use of a SubscriptionList allows for tracking all the subscriptions

I did not yet have a look into the details. In our solution we unsubscribe all previous subscriptions manually... thats kind of suboptimal atm on our end