If your only concern on the client side is to not pile up messages then
why don´t you simply use a topic for the reply?
Give each client his own topic on the broker by the servers. If there is
no client listening on the topic then the message can be simply discarded.
This has the advantage that
So, instead of having N brokers (1 per consumer), why not have N
destinations (1 per consumer)? If possible, further simplify it to less
than N destinations if you can shard/group your messages (don't know your
domain) and just use message properties and selectors to filter them at the
time of retr
>>So, that request-response recipe uses temporary destinations to route
messages. Your use-case is that of request-throttling and load-balancing the
'service'.
Not really. There is no service but a transport queue which could be IPC for
that matter. I may not have explained it well but I have the
So, that request-response recipe uses temporary destinations to route
messages. Your use-case is that of request-throttling and load-balancing
the 'service'. Why not use something designed for that purpose like nginx
and its http_limit_conn module? ActiveMQ does have the producer
flow-control featu
Thanks a lot for the code. I looked at it but if you can provide some
comments it might help as I am only familiar with whats at
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
and not inner workings.
But first question that comes to mind is if HTTP is right proto
To register an HttpCallback, you can create a class with a simple method
like below and just register the messagelistener at message publish time
(since your producers seem to know the message route upfront). This can be
called in a pooled thread on the client side:
void invokeEndpoint() {
Thanks. Few clarifications:
>>register an http-callback in the garb of a message listener
I am not sure I follow how to do this. (Note: We are using CMS instead of
JMS here). Is there a code snippet (JMS itself) that can quickly explain
what should be done ?
As to why we want to do that is due t
So you can always register an http-callback in the garb of a message listener
during the time of msg publication. When the client execs your listener and
runs the callback, it can do http post/get, etc to whatever other broker url
you want to route the msg to.
I am not sure what multiple broke
