Hi,
I just realised that my use case is unclear, so I'll try to describe it. I have an application that connects to the java broker and sends messages to a queue. There is not necessarily a consumer/receiver connected to that queue, it may connect and receive messages arbitrarily over time, but I cannot rely on that. Now, what I want to achieve is that if a certain threshold is met, e.g. a certain total message size in bytes or a total message count, the sender slows down sending or blocks on sending until a receiver starts to consume messages from the queue. The goal is to avoid that the queue contains too many messages. One idea that comes to my mind is to use the REST interface to query the queue, extract the queueDepthMessages or queueDepthBytes property from the statistics, and only send messages if the queue depth is below the defined threshold. However, that solution would comprise a fairly high overhead I'd like to avoid. Is there a possibility to achieve that by means of java broker (queue) configuration for AMQP 1.0? Best regards, Julien Avitech GmbH Engineering AxL Tel.: +49 (0)7541/282-177 Fax: +49 (0)7541/282-199 e-mail: [email protected] ________________________________________________ Avitech GmbH Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany Court Registration: Amtsgericht Ulm | HRB 728293 Geschäftsführer/Managing Director: Jon Joseba Goyarzu Caño http://avitech.aero This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. -----Ursprüngliche Nachricht----- Von: Julien Charon [mailto:[email protected]] Gesendet: Montag, 21. März 2016 08:59 An: [email protected] Betreff: AW: java broker queue flow control Hi Robbie, Thanks for the hint. But how can I manipulate the link credit for a JMS client acting as a receiver? I can't find anything in the documentation. Is there an example somewhere? Best regards, Julien Avitech GmbH Engineering AxL Tel.: +49 (0)7541/282-177 Fax: +49 (0)7541/282-199 e-mail: [email protected] ________________________________________________ Avitech GmbH Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany Court Registration: Amtsgericht Ulm | HRB 728293 Geschäftsführer/Managing Director: Jon Joseba Goyarzu Caño http://avitech.aero This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. -----Ursprüngliche Nachricht----- Von: Robbie Gemmell [mailto:[email protected]] Gesendet: Samstag, 19. März 2016 02:27 An: [email protected] Betreff: Re: java broker queue flow control If you do look, you'll probably want to force a low credit for the receiver links if playing with the newer JMS client: https://issues.apache.org/jira/browse/QPIDJMS-159 (I'm also on vacation, but probably won't look at it..) Robbie On 18 March 2016 at 22:05, Rob Godfrey <[email protected]> wrote: > Hi Julien, > > as Robbie guessed, flow control based on queue capacity isn't > currently implemented for AMQP 1.0 connections to the Java broker. > I'm on vacation next week, but I may take a look to see how easy it > would be to add an implementation. > > -- Rob > > On 18 March 2016 at 19:12, Robbie Gemmell <[email protected]> wrote: > >> Hi Julien, >> >> Those docs are discussing the AMQP 0-x JMS client I believe. I know >> you were asking about the AMQP 1.0 JMS clients recently, so if you >> are using those then the details wont be applicable, particularly >> around log messages. >> >> In terms of queue flow control, governing ability to send works >> differently in AMQP 1.0 than in AMQP 0.x did, and I'm not sure what >> the broker does there, it may be that feature isnt yet functional for >> AMQP 1.0 producers. >> >> Robbie >> >> On 18 March 2016 at 13:59, Julien Charon <[email protected]> >> wrote: >> > Hi, >> > >> > >> > I'm currently trying to configure flow control on queue level as >> described in [1]. >> > I tried the following: >> > - Create a queue, set flow control settings: capacity = 1024, >> > resume >> capacity = 512 (I also tried with capacity = 10240, resume capacity = >> 5120 and capacity = 102400, resume capacity = 51200) >> > - With a QPID JMS client, send 100 messages with ~16KB each >> > - I can't see any log messages on broker side nor on client side as >> described in [1] (also tried to set log level to DEBUG) >> > - Sending of the messages by the client (producer) is not slowed >> > down >> nor blocked as describe in [1] >> > Did I make a mistake in configuration or did I misunderstand something? >> > >> > >> > [1] >> https://qpid.apache.org/releases/qpid-java-6.0.1/java-broker/book/Jav >> a-Broker-Runtime-Disk-Space-Management.html >> > >> > Best regards, >> > Julien >> > >> > Avitech GmbH >> > Engineering AxL >> > Tel.: +49 (0)7541/282-177 >> > Fax: +49 (0)7541/282-199 >> > e-mail: >> > [email protected]<mailto:[email protected]> >> > ________________________________________________ >> > Avitech GmbH >> > Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany >> > Court Registration: Amtsgericht Ulm | HRB 728293 >> > Geschäftsführer/Managing Director: Jon Joseba Goyarzu Caño >> > http://avitech.aero<http://avitech.aero/> >> > >> > This message may contain confidential information and is intended >> > only >> for the individual named. If you are not the named addressee you >> should not disseminate, distribute or copy this e-mail. Please notify >> the sender immediately by e-mail if you have received this e-mail by >> mistake and delete this e-mail from your system. >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] For >> additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
