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