limit or put delays between messages when draining

[Christopher Pisz <ch...@gmail.com>]

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.

Re: limit or put delays between messages when draining

[David Martin <da...@qoritek.com>]

Yes thanks for the update, it's interesting to consider scenarios like this.

Sometimes there are 3rd party consumers that you have no control over and
something has to be done server-side. In this case it might be that they
must receive every message up to x hours old so a low TTL wouldn't help and
then even without any backlog they cannot handle any significant rate of
throughput anyway.

Something like Camel if used for the relay component would do retry and
throttling in a sensible manner.


Dave


On Wed, 24 Mar 2021 at 11:52, Tim Bain <tb...@alumni.duke.edu> wrote:

> After sending my message, I re-read your message, and realized I'd
> misunderstood what you meant. With the relay component you describe, I
> agree that problems in the consumer won't impact the producer.
>
> You'd want to configure the broker so that those messages can't back up
> forever (maybe that's as simple as setting the TTL).
>
> Sorry for missing your point in my first response.
>
> Tim
>
> On Wed, Mar 24, 2021, 5:47 AM Tim Bain <tb...@alumni.duke.edu> wrote:
>
> > I'm saying that in the scenario where you're preventing the producer from
> > sending messages because the consumer has fallen behind, the inability to
> > send messages can impact the producer process if it's not designed
> > explicitly to handle that situation. Maybe the sending thread blocks
> > synchronously, preventing the process from doing other work. Or maybe
> > exceptions are thrown, so the process isn't blocked but maybe it never
> > executes the code after the message send. Or maybe it goes into a tight
> > retry loop and spams the logs, eventually filling the disk because the
> logs
> > were never configured to rotate.
> >
> > It's possible to architect the producer process so it continues to
> execute
> > correctly even if it's unable to send these messages, but you have to do
> > that consciously, and it's easy to mess up.
> >
> > The biggest architectural advantage of using messaging middleware is that
> > it lets you decouple the producer and consumer, of which one major
> > advantage is that slowness in one doesn't impact the other, and typically
> > systems are architected to take advantage of that. So while it's possible
> > to architect a system to limit the producer when the consumer is behind,
> > I'd be very hesitant to do so, and would strongly consider other
> approaches
> > such as speeding up the consumer or configuring the message broker to
> drop
> > messages not consumed within some time window (i.e. TTL).
> >
> > Tim
> >
> > On Tue, Mar 23, 2021, 11:51 AM David Martin <da...@qoritek.com> wrote:
> >
> >> 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 <da...@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, <
> >> > > christopherpisz@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.
> >> > > >
> >> > >
> >> >
> >>
> >
>

Re: limit or put delays between messages when draining

[Tim Bain <tb...@alumni.duke.edu>]

After sending my message, I re-read your message, and realized I'd
misunderstood what you meant. With the relay component you describe, I
agree that problems in the consumer won't impact the producer.

You'd want to configure the broker so that those messages can't back up
forever (maybe that's as simple as setting the TTL).

Sorry for missing your point in my first response.

Tim

On Wed, Mar 24, 2021, 5:47 AM Tim Bain <tb...@alumni.duke.edu> wrote:

> I'm saying that in the scenario where you're preventing the producer from
> sending messages because the consumer has fallen behind, the inability to
> send messages can impact the producer process if it's not designed
> explicitly to handle that situation. Maybe the sending thread blocks
> synchronously, preventing the process from doing other work. Or maybe
> exceptions are thrown, so the process isn't blocked but maybe it never
> executes the code after the message send. Or maybe it goes into a tight
> retry loop and spams the logs, eventually filling the disk because the logs
> were never configured to rotate.
>
> It's possible to architect the producer process so it continues to execute
> correctly even if it's unable to send these messages, but you have to do
> that consciously, and it's easy to mess up.
>
> The biggest architectural advantage of using messaging middleware is that
> it lets you decouple the producer and consumer, of which one major
> advantage is that slowness in one doesn't impact the other, and typically
> systems are architected to take advantage of that. So while it's possible
> to architect a system to limit the producer when the consumer is behind,
> I'd be very hesitant to do so, and would strongly consider other approaches
> such as speeding up the consumer or configuring the message broker to drop
> messages not consumed within some time window (i.e. TTL).
>
> Tim
>
> On Tue, Mar 23, 2021, 11:51 AM David Martin <da...@qoritek.com> wrote:
>
>> 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 <da...@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, <
>> > > christopherpisz@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.
>> > > >
>> > >
>> >
>>
>

Re: limit or put delays between messages when draining

[Tim Bain <tb...@alumni.duke.edu>]

I'm saying that in the scenario where you're preventing the producer from
sending messages because the consumer has fallen behind, the inability to
send messages can impact the producer process if it's not designed
explicitly to handle that situation. Maybe the sending thread blocks
synchronously, preventing the process from doing other work. Or maybe
exceptions are thrown, so the process isn't blocked but maybe it never
executes the code after the message send. Or maybe it goes into a tight
retry loop and spams the logs, eventually filling the disk because the logs
were never configured to rotate.

It's possible to architect the producer process so it continues to execute
correctly even if it's unable to send these messages, but you have to do
that consciously, and it's easy to mess up.

The biggest architectural advantage of using messaging middleware is that
it lets you decouple the producer and consumer, of which one major
advantage is that slowness in one doesn't impact the other, and typically
systems are architected to take advantage of that. So while it's possible
to architect a system to limit the producer when the consumer is behind,
I'd be very hesitant to do so, and would strongly consider other approaches
such as speeding up the consumer or configuring the message broker to drop
messages not consumed within some time window (i.e. TTL).

Tim

On Tue, Mar 23, 2021, 11:51 AM David Martin <da...@qoritek.com> wrote:

> 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 <da...@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, <
> > > christopherpisz@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.
> > > >
> > >
> >
>

Re: limit or put delays between messages when draining

[David Martin <da...@qoritek.com>]

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 <da...@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, <
> > christopherpisz@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.
> > >
> >
>

Re: limit or put delays between messages when draining

[Tim Bain <tb...@alumni.duke.edu>]

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 <da...@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, <
> christopherpisz@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.
> >
>

Re: limit or put delays between messages when draining

[David Martin <da...@qoritek.com>]

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, <ch...@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.
>

RE: limit or put delays between messages when draining

[Carl Walker <ca...@bekwam.com>]

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 second queue – the one listened to by the slow sender – would be throttled by the interval.

I’ve had to deal with this a few times recently.  Once, to accommodate a slow legacy system.  The other times were to purposefully throttle requests to keep in line with licensing terms.

Sent from Mail for Windows 10

From: Hiran Chaudhuri
Sent: Saturday, March 20, 2021 11:29 AM
To: users@activemq.apache.org
Subject: Re: limit or put delays between messages when draining

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 <
> > christopherpisz@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.
> > >

Re: limit or put delays between messages when draining

[Hiran Chaudhuri <hi...@gmx.net>]

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 <
> > christopherpisz@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.
> > >

Re: limit or put delays between messages when draining

[Carl <ca...@bekwam.com>]

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 <ch...@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.
>>
-- 
Carl Walker
President
Bekwam, Inc - https://www.bekwam.com
work: (240) 288-8381
cell: (301) 524-4648
mail: carl@bekwam.com

Re: limit or put delays between messages when draining

[Tim Bain <tb...@alumni.duke.edu>]

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 <ch...@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.
>