users@jersey.java.net

[Jersey] Re: Connection Retry on jersey 1.5 Client

From: Florian Hehlen <Florian.Hehlen_at_imc.nl>
Date: Thu, 3 Mar 2011 13:22:22 +0000

Hi,

This suggestion is a bit old but I feel I can contribute something here... after getting so much help from this forum.

I have implemented a retry filter and there are a few more things you will need to do. The issue is that you will get an exception only if the server is completely down. If say the server is down but the web-app is not running then you may want to do retries based on response status... but then it gets tricky

Here is my code:

private ClientResponse retry(final ClientRequest cr) {

        ClientResponse response = null;
        boolean retry = false;

            do {

                try {
                    response = getNext().handle(cr);

                    if (response.getStatus() > MAX_OK_STATUS && !response.getHeaders().containsKey(HEADER_APP_STATUS)) {

                        retry = true;

                        if (outageWindowClosed()) {
                            retry = false;
                        } else {
                            sleep();
                        }

                    } else {
                        retry = false;
                        caught = null;
                    }

                } catch (ClientHandlerException e) {
                    caught = e;

                    if (outageWindowClosed()) {
                        retry = false;
                    } else {
                        sleep();
                    }
                }

            } while (retry);

           //resume behavior that would happen without this filter
            if (caught != null) throw caught;

            windowEndsAt = 0L;

        return response;
    }

Note that I have made my implementation time based which means that server operators actually have an reliable time-window in which the server can be restarted. Note also that my app sends back special headers. When the app triggers a 404 status(ex: entity not found) which would be different than the 404 sent back as a default by tomcat(ex: during start-up, incorrect url, etc).

Cheers,
florian

From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
Sent: Tuesday, February 15, 2011 2:57 PM
To: SISE Inc.; users_at_jersey.java.net
Subject: [Jersey] Re: Connection Retry on jersey 1.5 Client

Hi again,

sure, it is fairly simple - you should improve this (add some checks etc), but it is usable:

        Client c = client();

        c.addFilter(new ClientFilter() {
            private final int maxRetries = 3;

            @Override
            public ClientResponse handle(ClientRequest cr) throws ClientHandlerException {

                int i = 0;

                while(i < maxRetries) {

                    i++;

                    try {
                        return getNext().handle(cr);
                    } catch (ClientHandlerException e) {

                        // you migh want t check e.getClause, i.e. something like
                        // if(e.getClause() instanceof ConnectException) { ... } else { throw e; }
                        Logger.getLogger("myFilter").log(Level.INFO, "Connection Timeout (" + cr.getURI() + "), will try " + (maxRetries - i) + " more time(s).", e);
                    }
                }
                throw new ClientHandlerException("Connection retries limit exceeded.");
            };
        });

        c.resource("http://oracle.com"<http://oracle.com>).get(String.class);


I guess you would like to extract this to standard class and put connection retries as a parameter to constructor.. or anything else - depends on your requirements.

Hope it helps.

Regards,
Pavel

On 02/09/2011 08:49 PM, SISE Inc. wrote:
Hello Pavel,

The ReadTimeout have a ClientConfig property that I set on ClientRequest.

I would appreciate any tip you can give on this filter... I'm only using the Jersey Client API. Just a newbie on this topic.. Though the app works perfectly now, we just want a way to retry dropped connection..

Regards,
Tim
SISENT

From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
Sent: Monday, February 07, 2011 7:11 AM
To: users_at_jersey.java.net<mailto:users_at_jersey.java.net>
Subject: [Jersey] Re: Connection Retry on jersey 1.5 Client

Hello Sisent,

this is not "standard" http option in Java SE, but you can easily implement it by yourself, similarly to ReadTimeOut filter you are using. There is no limit to what you can do in filter, for example you can do multiple subsequent requests (which is almost what you need), see HTTPDigestAuthFilter.handle().

And, if you want, you can file and RFE afterwards, include your patch and filter you implemented can be included in next release.

Pavel

On 02/04/2011 11:43 PM, SISE Inc. wrote:
Hi,

How do I set the number of Connection retry on the Client if I have the following code to get my WebResource?

  ClientConfig cc = new DefaultClientConfig();
  Client c = Client.create(cc);
  c.addFilter(new LoggingFilter()); //Login Filter
  resource = c.resource(buri);
  resource.addFilter(new ReadTimeOut(timeOut)); // Time out filter for Timeout

The ClientConfig does not have any option for Connection Retry... Any help on this?

Regards,
sisent




________________________________

The information in this e-mail is intended only for the person or entity to which it is addressed.

It may contain confidential and /or privileged material. If someone other than the intended recipient should receive this e-mail, he / she shall not be entitled to read, disseminate, disclose or duplicate it.

If you receive this e-mail unintentionally, please inform us immediately by "reply" and then delete it from your system. Although this information has been compiled with great care, neither IMC Financial Markets & Asset Management nor any of its related entities shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachments. In the event of incomplete or incorrect transmission, please return the e-mail to the sender and permanently delete this message and any attachments.

Messages and attachments are scanned for all known viruses. Always scan attachments before opening them.