Ah, I see. Yes, so the client needs to reissue the subscribes on reconnect to re-establish the individual handlers.
But you should be able to short circuit this if it is just the same application, the same client instance reconnecting after a broken connection. In that case you should not need to go through the subscribes again.
Marc L. Cohen
MessageSight Test/Development
Internet:mlcohen@xxxxxxxxxx
also at:teddybbear@xxxxxxx
(512) 286-5744 (T/L 363-5744)
FAX (512) 973-4293
Ian Craggs ---05/06/2015 10:05:40 AM---The application can be completely new, so the only way of reestablishing a message handler automati
From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To: paho-dev@xxxxxxxxxxx
Date: 05/06/2015 10:05 AM
Subject: Re: [paho-dev] Java client: per subscription message handling callbacks
Sent by: paho-dev-bounces@xxxxxxxxxxx
The application can be completely new, so the only way of reestablishing a message handler automatically would be by reflection, as far as I can see. And that would be unreliable.
It's the same situation as the default message handler - you have to set the callback again when the client object is recreated.
In this case, the call to set the message handler is subscribe(), so if we call subscribe() again we could optimize by not issuing the MQTT subscribe packet (as long as cleansession is false on both sessions).
Ian
On 05/06/2015 03:27 PM, Marc L Cohen wrote:
Obviously, the information on the subscriptions would need to be added to the persistent store in order to reestablish the per subscription message handlers, but on restart it should be able to just take that information from the persistent store and reestablish the handlers without reissuing the subscribes.
Marc L. Cohen
MessageSight Test/Development
Internet:mlcohen@xxxxxxxxxx
also at:teddybbear@xxxxxxx
(512) 286-5744 (T/L 363-5744)
FAX (512) 973-4293
Ian Craggs ---05/06/2015 09:19:11 AM---Oh yes, so do I :-). And it's allowed by the MQTT 3.1.1 specification, so it's something we have t
From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To: paho-dev@xxxxxxxxxxx
Date: 05/06/2015 09:19 AM
Subject: Re: [paho-dev] Java client: per subscription message handling callbacks
Sent by: paho-dev-bounces@xxxxxxxxxxx
Oh yes, so do I :-). And it's allowed by the MQTT 3.1.1 specification, so it's something we have to expect.
The edge case I was referring to was the "overlapping" subscriptions, and using per subscription message handlers. You probably never need overlapping subscriptions, and if you do, you can use the default message handler.
Another question that springs to mind is, if you reinstantiate a client object from persistent store, how do you reestablish the per subscription message handlers? Calling the subscribe method again is the obvious solution, but does the client try to optimize by not sending the MQTT subscribe request again?
Ian
On 05/06/2015 03:03 PM, Marc L Cohen wrote:
I know of at least one server that does send the message to each subscription.
Marc L. Cohen
MessageSight Test/Development
Internet:mlcohen@xxxxxxxxxx
also at:teddybbear@xxxxxxx
(512) 286-5744 (T/L 363-5744)
FAX (512) 973-4293
Ian Craggs ---05/06/2015 08:59:15 AM---Hi Roger, good point :-) The embedded client stops at the first match. But in
From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To: paho-dev@xxxxxxxxxxx
Date: 05/06/2015 08:59 AM
Subject: Re: [paho-dev] Java client: per subscription message handling callbacks
Sent by: paho-dev-bounces@xxxxxxxxxxx
Hi Roger,
good point :-) The embedded client stops at the first match. But in that case I want to take every step to minimize processing and resource usage, so it seems like the right thing to do.
I guess if it's an edge case, it may not matter, as long as we are clear what the behaviour is.
Let's see if we get any votes...
Ian
On 05/06/2015 02:47 PM, Roger Light wrote:
Hi Ian,
I refer you to the first line of your previous answer :) You're right, it would be undesirable in that situation, but it's a bit of an edge case.
Cheers,
Roger
On Wed, May 6, 2015 at 2:42 PM, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Roger,
in the case of a server sending out a message for each matching subscription, this would result in a proliferation of messages, which seems undesirable to me.
Ian
On 05/06/2015 02:39 PM, Roger Light wrote:
Hi,
The Python client does this and checks every callback filter to see if it matches, and hence will deliver a single message to multiple callbacks if they overlap. It will deliver the message to the "global" callback if it does not match any of the filtered callbacks.
Cheers,
Roger
On Wed, May 6, 2015 at 2:30 PM, Marc L Cohen <mlcohen@xxxxxxxxxx> wrote:
What is the proposal for deciding which subscription if the topic matches more than one subscription and the server only sends one message, or if it sends one per subscription?
Marc L. Cohen
MessageSight Test/Development
Internet:mlcohen@xxxxxxxxxx
also at:teddybbear@xxxxxxx
(512) 286-5744 (T/L 363-5744)
FAX (512) 973-4293
Ian Craggs ---05/06/2015 08:13:13 AM---I'm proposing to add per subscription message handling callbacks to the Java client.
From: Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To: General development discussions for paho project <paho-dev@xxxxxxxxxxx>
Date: 05/06/2015 08:13 AM
Subject: [paho-dev] Java client: per subscription message handling callbacks
Sent by: paho-dev-bounces@xxxxxxxxxxx
I'm proposing to add per subscription message handling callbacks to the
Java client.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466579
This will mean having to parse and match the incoming topics, as MQTT
does not send the subscription topic with each message, but the topic on
which the original message was published. I have some simple code that
does that in the embedded C++ client however.
Any thoughts or comments welcome, here or in the bug....
Thanks
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
|