Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Java client: per subscription message handling callbacks
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

Inactive hide details for Ian Craggs ---05/06/2015 09:19:11 AM---Oh yes, so do I :-). And it's allowed by the MQTT 3.1.1 speciIan 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

    Inactive hide details for Ian Craggs ---05/06/2015 08:59:15 AM---Hi Roger, good point :-) The embedded client stops at the firIan 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:


          _______________________________________________
          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

Back to the top