If the same application is reconnecting after a broken connection,
then it doesn't need to delete and recreate the client object.
Normally it would just use the same object, and then you wouldn't
have to reissue the subscribes.
Technically, if you recreate the client object within the same
application, you could reestablish the links with the callback
handlers. However, they may have been garbage collected, and again
this is just too prone to errors.
So the only alternative to reissuing the subscribes() again, as far
as I see it, is to have a separate setSubscriptionHandler() or
similar method, which establishes a handler without (re)issuing the
MQTT subscription. This would be in addition to the other methods.
Ian
On 05/06/2015 04:19 PM, Marc L Cohen
wrote:
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
_______________________________________________
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
|