Hi Gerard, could you possibly elaborate on this? We want senders and receivers be completely separated, they are different applications.
-----Original Message----- From: Weatherby,Gerard <gweathe...@uchc.edu> Sent: woensdag 14 oktober 2020 14:20 To: users@qpid.apache.org Subject: Re: Non-blocking Sender with no Receivers I don’t know if this would work, but have you tried making your senders receivers of their own messages? -- Gerard Weatherby | Application Architect NMRbox | Department of Molecular Biology and Biophysics | UConn Health 263 Farmington Avenue, Farmington, CT 06030-6406 uchc.edu > On Oct 14, 2020, at 8:16 AM, Petrenko, Vadim <vadim.petre...@ns.nl> wrote: > > *** Attention: This is an external email. Use caution responding, > opening attachments or clicking on links. *** > > Good day, > > We’re trying to implement our Qpid dispatch router network in such a way that > a sender can connect to it at any moment and start sending messages to a > topic. > There might be no receivers at this moment, so the messages would be just > lost. This is ok. > Then an any moment a receiver(s) can connect and start receiving messages > currently being sent, then drop off. The sender will just continue sending > messages, probably into the void. > > It’s about sending data from sensors. Sensor data is short living and there > is no need to buffer it or persist. If no one consumes this data in realtime, > it can be lost. > Senders and receivers in our situation are quite volatile, they appear and > drop off. > > As per docs of Qpid: > === > Dispatch Router uses a credit-based flow control mechanism to ensure that > producers can only send messages to a router if at least one consumer is > available to receive them. Because Dispatch Router does not store messages, > this credit-based flow control prevents producers from sending messages when > there are no consumers present. > === > > I was wondering, maybe there is still a workaround or a trick to implement > the router network the way I described in the beginning? > If possible without extra brokers and only with Qpid dispatch routers? > > Thanks. > > > ________________________________ > > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke > informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of > verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan > derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde > geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond > hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) > te vernietigen. > > Informatie > vennootschap<https://urldefense.com/v3/__http://www.ns.nl/emaildisclai > mer__;!!N0rdg9Wr!6nw7f_PTi-MsxBR4wWT6OhEcRjT3xrahFXs8pbYzYdtf6O6DZb-nj > fmu49tteveosDU$ > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org ________________________________ Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen. Informatie vennootschap<http://www.ns.nl/emaildisclaimer> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
