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
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

Inactive hide details for Ian Craggs ---05/06/2015 10:05:40 AM---The application can be completely new, so the only way of reesIan 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

    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

_______________________________________________
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