activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gaurav Sharma <>
Subject Re: Implementing Request Response mechanism
Date Mon, 20 Aug 2012 19:40:59 GMT
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() {
        boolean success = false;
        try {
            RestClient client = new RestClient();
            Resource resource = client.resource(url);
            // default content-type
            if (method != HttpMethod.DELETE && headers != null
                && !headers.containsKey("Content-Type"))
                headers.put("Content-Type", "application/json");
                for (Map.Entry<String, String> entry : headers.entrySet()) {
                    resource.header(entry.getKey(), entry.getValue());
            MultivaluedMap queryParamsMap = new MultivaluedMapImpl();
            mapToMultiValuedMap(queryParams, queryParamsMap);
            if (queryParamsMap.size() > 0) {
            ClientResponse response = null;
            switch (method) {
                case POST:
                    response =, payload);
                case GET:
                    response = resource.get(ClientResponse.class);
                case DELETE:
                    response = resource.delete(ClientResponse.class);
                case PUT:
                    response = resource.put(ClientResponse.class, payload);
                case HEAD:
                    response = resource.head();
                case OPTIONS:
                    response = resource.options();
            if (response != null) {
                int statusCode = response.getStatusCode();
                if (statusCode < 400) {
                    success = true;
        } catch (Exception remoteExecException) {
            // log or walk down the fault tree
        if (!success) {
            // can retry with exponential backoff

As far as the messages piling up in the broker, in a high volume setting,
there usually is a sane TTL on the message/destination since consumer
failures are necessarily assumed to happen.

Looks like this line sums up what you are trying to safeguard against:
"Idea is that if it can be consumed by consumers only then we should send
So, to that point, why do you need a messaging service in the middle if
your consumers are always required to be connected and expected to
synchronously consume messages - is it because they cannot consume the
messages fast enough? And if the answer is yes, then my deduction is that
you trying to use the messaging service/broker as a sort of
rate-control/throttling mechanism between client-server?

On Mon, Aug 20, 2012 at 11:16 AM, zackhasit <> wrote:

> 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 to more real time nature of
> applications
> here. Idea is that when client goes down we want receive broker to catch it
> immediately and if server goes down we want server broker to catch that
> immediately also.
> If you look at link here :
> It says: "if there are no consumers on a certain broker messages could just
> pile up without being consumed. We have an outstanding feature request to
> tackle this on the client side - but currently the solution to this problem
> is to create a Network of brokers to store and forward messages between
> brokers."
> We don't want any pile up of messages and would have our client to make
> decisions itself. These are real time events and if we cant get a response
> then there is no point in sending them.
> Store and forward which has been suggested above also wouldn't work because
> we don't know how long it would store them before forwarding (increasing
> latency again). Idea is that if it can be consumed by consumers only then
> we
> should send it.
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message