activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gaurav Sharma <gaurav.cs.sha...@gmail.com>
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) {
                resource.queryParams(queryParamsMap);
            }
            ClientResponse response = null;
            switch (method) {
                case POST:
                    response = resource.post(ClientResponse.class, payload);
                    break;
                case GET:
                    response = resource.get(ClientResponse.class);
                    break;
                case DELETE:
                    response = resource.delete(ClientResponse.class);
                    break;
                case PUT:
                    response = resource.put(ClientResponse.class, payload);
                    break;
                case HEAD:
                    response = resource.head();
                    break;
                case OPTIONS:
                    response = resource.options();
                    break;
            }
            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
it."
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 <zackhasit@gmail.com> 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 : http://activemq.apache.org/clustering.html
>
> 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:
> http://activemq.2283324.n4.nabble.com/Implementing-Request-Response-mechanism-tp4655304p4655325.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

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