I expect Gerard means that if you also created a receiver that received your multicasted messages, then you would definitely be granted credit to send to the address, since you have ensured there is definitely a receiver (you, plus maybe others)
On Wed, 14 Oct 2020 at 14:27, Petrenko, Vadim <vadim.petre...@ns.nl> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
