Hello, I have a last value queue and I would like to implement a proton C++ client that read the whole queue in browse mode and exit gracefully. How can I get the event that there are no more messages in the queue? Is it possible with proton API to get the queue size ?
Best regards, Daniel > On 14. Jan 2018, at 16:04, Daniel Gavrila <[email protected]> wrote: > > > > Thanks Jakub for suggestion! > >> On 14. Jan 2018, at 15:12, Jakub Scholz <[email protected]> wrote: >> >> How do you plan to implement this: "Before the shutdown the sensor remove >> its entry from the queue."? >> >> If you plan to have large amount of sensors (= a lot of messages in the >> StatusOverview queue) which would shutdown often, finding and accepting the >> particular message might not be the optimal way to do this. So maybe you >> can instead send a message which would contain in the properties or body >> the information that the sensor is shutting down. It would overwrite the >> previous status and later expire and be removed automatically. >> >> Regards >> Jakub >> >> On Sun, Jan 14, 2018 at 2:46 PM, Daniel Gavrila <[email protected]> >> wrote: >> >>> >>> These are good news! >>> I think I'm able now to translate the use case scenario in "AMQP language" >>> >>> Each sensor publish a durable message with TTL=N seconds to the LVQ >>> durable queue StatusOverview every N seconds. >>> Each GUI client read the queue OverviewStatus in browse mode. >>> Before the shutdown the sensor remove its entry from the queue. >>> If a abnormal exit occurs the queue will remove the entry after maxim N >>> seconds >>> >>> I have one more general question. Which relation is between qpid-config >>> and the qpid::messaging API ? Everything that can be done with qpid-config >>> can be done also with the API ? >>> >>> Best regards, >>> Daniel >>> >>> >>>> On 13.01.2018, at 17:23, Jakub Scholz <[email protected]> wrote: >>>> >>>> The LVQ queue is able to persist these messages to disk like any other >>>> queue. So they can survive restart. >>>> >>>> Jakub >>>> >>>> On Sat, Jan 13, 2018 at 4:55 PM, Daniel Gavrila <[email protected]> >>>> wrote: >>>> >>>>> Hello Andreas, >>>>> >>>>> Thanks for the suggestion.From what I read from documentation, indeed a >>>>> last value queue should cover a signifiant part of use case >>>>> scenario.Remains the question if the values from a LVQ could be make >>>>> persistent, so that will be recovered after a broker restart? >>>>> >>>>> Best regards, >>>>> Daniel >>>>> >>>>> >>>>>> On 13.01.2018, at 12:55, Andreas Welchlin <[email protected]> wrote: >>>>>> >>>>>> Hello Daniel, >>>>>> >>>>>> this should work using a last value queue. >>>>>> >>>>>> Kind Regards, >>>>>> Andreas >>>>>> >>>>>> Am 13. Januar 2018 12:19:57 MEZ schrieb Daniel Gavrila < >>>>> [email protected]>: >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> My environment is: >>>>>>> C++ Proton v. 0.19 >>>>>>> C++ Broker v.1.37 configured with AMQP 1.0 >>>>>>> >>>>>>> I have to implement the following use case scenario. The network >>>>> contains N publishers(sensors) . When one sensor starts it publish to >>> the >>>>> queue OverviewStatus one message that contains some data: sensor >>>>> name,type,internal status etc. One GUI program has to display the >>>>> information from the queue OverviewStatus. Everytime the sensor changes >>> its >>>>> internal status he needs to update the status in the queue.Before the >>>>> shutdown , the sensor has to remove its entry from the queue. >>>>>>> If the sensor exits anormaly the event should be catched and the >>> sensor >>>>> status modified accordingly. By restarting the broker, all the sensors >>>>> status information should be recovered. >>>>>>> >>>>>>> Is it possibly to implement such use case in the above mentioned >>>>> environment? Any suggestions are welcomed ! >>>>>>> >>>>>>> Many thanks, >>>>>>> Daniel >>>>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
