We ended up with a less than ideal solution for now. We're using camel to
slowly take messages off one queue and put them on another. This is not
ideal, because if the app is stopped, camel will keep moving messages. We
also had to exclude the `THROTTLE.>` destinations from being sent across any
It's a text messaging service, Twilio. So we can actually call their API as
many times as we want, and they will queue up messages to send out at 1
msg/sec. The problem is, even at 1msg/s, the cell phone carriers don't like
a single person sending the similar messages over and over again. So if
> but this one is accessing an external resource that will error out if we
go too fast.
Out of curiosity (and because it might help with suggestions), what's the
external resource? Its "sounds" like a rate limited external webservice,
but I'm just guessing.
Sounds like we could wrap the
I know right? It's sort of funny actually. We have one instance of TomEE
processing 5k+ msg/s for another purpose, but this one is accessing an
external resource that will error out if we go too fast.
We can choke resources by limiting the pool and maxSessions, but we need
something more
I have had that same problem before in my previous company. We did kind of
a hack at that time.
So short answer, there is nothing available to control the consuming rate.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Tue, Feb 26, 2019 at 5:53 PM Jonathan
You're consuming messages too quickly? Sounds like a good problem to have
:). I'm not aware of a rate limit facility in the connector code. You can
tweak the MDB pool to have less concurrency, and lower throughput as a
result. There was a change I made with Ivan to provide the same sort of
pooling
Here's a problem I never thought I'd have... we need to rate limit the rate
and which we process a message queue.
Is there a facility in TomEE to do this? I looked around the MDB dispatch
code and didn't see anything specifically.
Thanks,
-Jonathan
--
Sent from:
