On Wed, 14 Oct 2020 at 14:18, Ken Giusti <kgiu...@redhat.com> wrote: > > On Wed, Oct 14, 2020 at 8:25 AM Petrenko, Vadim <vadim.petre...@ns.nl> > wrote: > > > 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. > > > > > Can your sending client first check whether or not there is credit on the > link and if there is no credit simply drop the message rather than sending > it? > Getting the value of available credit depends on the client API you are > using. For example in Proton-C your sender would call > pn_link_credit(sending_link_ptr) to get the credit for the sending link. > > Also keep in mind that since the application is OK with messages being > dropped you'll want the sender to settle the message after it is sent > (a.k.a. "pre-settled). > >
Though it may not be the only type of client in use, Qpid JMS was mentioned in another thread. It isn't possible to check credit there, the client blocks for credit (you can set a sendTimeout and the client will fail a send if it doesn't get credit). Alternatively, might I suggest use of anonymous producer links (producers to the null address)? I believe they are always granted credit to send, since it's not possible for the router to tell in advance where their messages are going to be sent, it can only identify that once they arrive. If so, you can create JMS senders that use the anonymous sender, either by omitting the destination when creating a MessageProducer instance, or using JMSProducer instances which always use anonymous senders. You can also configure the client via the URI to send messages pre-settled if desired. With talk of pre-settling however, also note the router aggressively manages incoming pre-settled message backlog while messag-routing (as opposed to link routing) in order to avoid congestion. Robbie --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
