On Wed, 14 Oct 2020 at 17:18, Robbie Gemmell <[email protected]> wrote: > > On Wed, 14 Oct 2020 at 15:55, Petrenko, Vadim <[email protected]> wrote: > > > > Hi Ken, > > > > Yes, we're pre-settling messages already: > > connectionfactory.myFactoryLookupSender = > > amqp://localhost:5674?jms.presettlePolicy.presettleProducers=true > > (dockerized Qpid with an exposed port). > > > > Making the sending client first check for available credits is a > > possibility, but not the ideal option we'd like to use. These clients are > > not in our control, it's other teams that develop their applications using > > our Qpid network. So we can't really enforce them. Only advise. > > > > The JMS client can't do that anyway. > > > I also noticed some strange behavior which I don't understand. Maybe you > > guys can explain. > > I've taken the Sender and Receiver from qpid-jms-examples, connected them > > to our router network and observed how this works. > > 1. When I start the Sender, it gets blocked because there is no receiver > > (in the logs I see "Holding Message send until credit is available"). This > > is as expected. > > 2. I start the Receiver, messages begin to flow, all good. > > 3. I kill the Receiver process, but the Sender is still sending messages. > > To nowhere. It doesn't timeout either. > > It's sending them to the router, which it still has outstanding credit > to do. It knows nothing of the receiver. > > It won't time out a send unless you configure it to, and note it > certainly won't time out in this case if it has credit to send and is > sending pre-settled messages, since there is also no response to wait > for. > > > > > I then proceeded debugging AmqpFixedProducer, which works with credits, and > > noticed that on step 1 number of credits it gets via > > getEndpoint().getCredit() is 0. So it holds the message. > > On the next step Receiver gives it 250 credits. After that, even though the > > Receiver process is killed, the number of credits is still 250 and doesn't > > get decremented. The Sender continues to send. I expect that credits would > > be exhausted at some point. > > Is this as it should be? > > Are you sure it 'doesn't get decremented' (which happens locally as > sends occur), or are you perhaps just not observing the credit is > being replenished by the router? You can see the protocol trace on > router and/or the client by running them with env variable > PN_TRACE_FRM=1 set (or also for client, see: > http://qpid.apache.org/releases/qpid-jms-0.54.0/docs/index.html#logging) > > As you are using message-routing, the router itself is what grants the > sender credit to send. The receiver also grants credit but that is to > the router, and is quite independent of the credit the sender will see > from the router (credit would be aligned end to end for a link-routing > case, e.g through router to/from a broker). > > https://issues.apache.org/jira/browse/DISPATCH-1090 is the last I can > think of the behaviour in this area being tweaked, which was to try > and drain the outstanding credit in similar cases, however in checking > the vicinity of those changes now, I see edge routers being called out > and handled differently, indicating it will replenish the credit for > such messages. Your other thread mentioned edge routers so I think > perhaps this is in play here: > https://github.com/apache/qpid-dispatch/blob/1.14.0/src/router_core/transfer.c#L467-L476 >
Actually, though it may still be in play in the larger picture, it won't be in the way I was originally thinking since I wasn't considering the correct link. Needs folks with more(/any) router knowledge than me to reason about :) > > > > Thanks. > > > > > > -----Original Message----- > > From: Ken Giusti <[email protected]> > > Sent: woensdag 14 oktober 2020 15:18 > > To: users <[email protected]> > > Subject: Re: Non-blocking Sender with no Receivers > > > > On Wed, Oct 14, 2020 at 8:25 AM Petrenko, Vadim <[email protected]> > > 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). > > > > > > > > > > > > ________________________________ > > > > > > 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> > > > > > > > > > -- > > -K > > > > ________________________________ > > > > 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: [email protected] For additional commands, e-mail: [email protected]
