7 Replies Latest reply: Jul 11, 2012 9:53 AM by Michael Daleiden RSS

Is it possible to configure a service with a client-specified timeout?

Michael Daleiden Newbie

We are currently using SOA-P 5.1 (JBossESB), but are looking to evaluate SwitchYard as it is the replacement for JBossESB in 6.0. An initial question that as come up is whether a service can be configured with a client-specified timeout value, such that if the service does not respond within the given timeout period, it fails with a consistent exception that can be caught so that we can then return a consistent error XML response (something like this):

 

<ServiceResponse>

<Errors>

<Error type="timeout">The requested service did not complete within the specified timeout</Error>

</Errors>

</ServiceResponse>

 

Our current ESB implementation utilizes ServiceInvoker.deliverSync() to accomplish this, passing in the client-specified timeout and catching the ResponseTimeoutException. We would like to do something similar in SY.

  • 1. Re: Is it possible to configure a service with a client-specified timeout?
    Łukasz Dywicki Novice

    Hey Michael,

    Currently switchyard don't have a typical client library. However you can use Apache Camel to do such things. You can use camel to execute ESB or to call some external service from ESB. Because every component have different configuration - some of them support timeouts some of them doesn't have this feature it's hard to provide a general purpose library.

    For example you can do:

    try {

      Future<Object> future = camelContext.createProducerTemplate().asyncSendBody("endpointUri", requestBody);

      future.get(60, TimeUnit.SECONDS)

    } catch (TimeoutException e) { /* response did not arive */ }

     

    If you would like to have something more flexible, there is a RoutePolicy interface which can be used to implement throttler or custom. endpoint independent, timeout support. RoutePolicy have necessary method from your point of view onExchangeBegin.

  • 2. Re: Is it possible to configure a service with a client-specified timeout?
    Keith Babo Master

    The point about RoutePolicy is an interesting one.  I wonder if you could use that and/or interceptors in the route to effectively set up a execution time boundary for the route.  If the max execution time is exceeded, the route would stop and a configurable error handler could kick in to generate a response.  That would be cool. It would also allow you to specify this via config vs. writing code and would generalize the solution.  Please keep me honest if I'm reaching here, Lukasz. :-)

  • 3. Re: Is it possible to configure a service with a client-specified timeout?
    Łukasz Dywicki Novice

    I've done some prototype on my local and seems it works:

     

    public class TimeoutRoutePolicy extends RoutePolicySupport {

     

        private Map<Exchange, Long> execTime = Collections.synchronizedMap(new HashMap<Exchange, Long>());

     

        @Override

        public void onExchangeBegin(Route route, final Exchange exchange) {

            execTime.put(exchange, System.currentTimeMillis());

     

            new Thread(new Runnable() {

                @Override

                public void run() {

                    try {

                        Thread.sleep(3000); // fixed rate timeout conunter

                    } catch (InterruptedException e) { }

                    exchange.setProperty(Exchange.ROUTE_STOP, Boolean.TRUE);

                    exchange.setException(new TimeoutException());

                }

            }).start();

        }

     

        @Override

        public void onExchangeDone(Route route, Exchange exchange) {

            Long begin = execTime.remove(exchange);

            System.out.println(exchange.getExchangeId() +" processing time "+ ((System.currentTimeMillis() - begin) +" ms"));

        }

     

    }

     

    It do have an drawback, first of all it won't cancel a request sent to external system, it will just prevent camel from continuation of work. For example if route looks like this:

    from(input).to(longOperation).to(longOperationPostProcessor)

     

    Camel will wait till longOperation completes and then cancel rest of the flow - in this case longOperationPostProcessor won't be called.

  • 4. Re: Is it possible to configure a service with a client-specified timeout?
    Keith Babo Master

    Thought about this a bit yesterday and realized that we could build support for this directly into the SwitchYard component.  It could be an endpoint configuration parameter that could also be specified/overridden as a message header.  The only sticky point is precisely what you mentioned w/r/t the blocking of the invocation.  If the invocation exceeds the timeout, then you're waiting around until it completes before replying back.  That's straightforward enough to implement, but it's gonna require some deeper surgery in core.  I actually have some other evil plans in that area, so I'll package up all of my thoughts together and reply next week.

  • 5. Re: Is it possible to configure a service with a client-specified timeout?
    Michael Daleiden Newbie

    Thanks, Keith. Any more thoughts on how this might be handled?

  • 6. Re: Is it possible to configure a service with a client-specified timeout?
    Keith Babo Master

    Been busy with getting 0.5.0.Final out the door, so I haven't had a chance to really elaborate on what we will do.   The two pieces that are required are:

     

    - Handling a timeout on a specific invocation of a service within a route.

    - Setting a timeout on an overall route execution.

     

    I think we can handle both of these with some deeper Camel integration I have planned for 0.6.   I have filed a JIRA for 0.6 and we will include tests and maybe a quickstart to demonstrate how it's used.  I will make sure we post details on the proposed implementation early on so you can provide feedback.

     

    https://issues.jboss.org/browse/SWITCHYARD-920

  • 7. Re: Is it possible to configure a service with a client-specified timeout?
    Michael Daleiden Newbie

    Thanks, Keith. I've set up a watch on the JIRA issue, so as soon as you post details, I'll take a look and provide feedback.