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 for the next message. I believe that approach will only work when at the same time you limit how many threads can be used to process messages in parallel. Looking overall it seems to me you may have a problem in parallel processing such messages. Limit your client to only allow one message processing thread. If need be add the delay. But all that looks like workarounds to a real issue. Try to figure out where that is. Hiran On Sat, 2021-03-20 at 10:44 -0400, Carl wrote: > 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 > TimerService so that the field engineers can configure the interval. > > -Carl > > On 3/20/21 10:33 AM, Tim Bain wrote: > > 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 < > > christopherp...@gmail.com> > > wrote: > > > > > I am using Artemis with Websockets and STOMP > > > > > > A third party I am working with suspects that their software is > > > having > > > trouble when there are many messages queued up and they connect, > > > then > > > receiving back to back messages until the queue drains. > > > > > > Is there a way to configure "Please pause x milliseconds between > > > sending > > > messages out to subscribers" or "pause x milliseconds between > > > sending each > > > message?" > > > > > > I know their network code is probably flawed, but this might > > > provide a > > > stopgap, so thought I'd ask. > > >
