Hi Tim, That's an interesting point. This is what I had in mind (assuming that the STOMP interface doesn't support the consumerMaxRate or consumerWindowSize parameters as they are only documented for Core & JMS?):
** Current state ** Fast Producer -> Outbound Queue -> Exclusive Slow Consumer using STOMP (which is sometimes offline and cannot handle a backlog) ** Proposal ** Fast Producer -> Outbound Queue -> server-side JMS/Core Relay using producerWindowSize=(small number) -> Buffer Queue -> Slow STOMP Consumer --- So are you saying that, as the Relay component will be blocked from publishing if the buffer queue is backed up, this will cause problems upstream? Dave On Tue, 23 Mar 2021 at 11:47, Tim Bain <tb...@alumni.duke.edu> wrote: > As an aside, while we wait for the OP to tell us whether any of these > suggestions are relevant to his situation: > > In most cases, you want producers and consumers to be decoupled, so that a > slow consumer doesn't block its producers. Flow control is typically used > to protect the broker and to prevent misbehaving clients on one destination > from affecting clients on other destinations. I would be very cautious > about any architecture that proposed the intentional linking of producer > processes and consumer processes via a flow control window, since it can > broaden the impact of problems beyond the process that is experiencing > them. > > Tim > > On Sat, Mar 20, 2021, 10:31 AM David Martin <dav...@qoritek.com> wrote: > > > 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 19, 2021, 11: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. > > > > > >
