Hello,
You could possibly try producer window-based flow control to stop messages
backing up on the queue when consumers are offline (e.g. using an
intermediate queue to store the backlog) -
https://activemq.apache.org/components/artemis/documentation/1.0.0/flow-control.html
Dave
On Fri, Mar
I’m not sure if you’re in an app server, but you could have the slow consumer
listen to a different queue. Your current sender posts as-is, but add another
listener (say a DelayAction) that uses that DB / programmatic EJB TimerService
to re-post a single message after a set interval. The
So far I thought with JMS and other messaging frameworks the clients
subscribe to messages. While doing so they would indicate they are
ready to process messages when they come in.
The sleep that was suggested would tell a client to process a message
and indicate only after a delay it is ready
I just implemented a similar requirement where one system was overruning
the other.
If you're running in an app server, you can use javax.ejb.TimerService.
My message listener stores the request in a DB. Sometime later, a timer
wakes up and process a singular item. I use the programmatic
If the third party simply puts a sleep at the end of their message-handling
logic, will that meet the need? If not, hearing what doesn't work about
that approach will help us to better understand exactly what's needed.
Tim
On Fri, Mar 19, 2021, 5:01 PM Christopher Pisz
wrote:
> I am using
