Hi Asankha,

> Ref: Address Endpoint
>
http://wso2.org/project/esb/java/1.6/docs/ESB_Configuration_Language.htm
l

Thanks for providing this link! Up to now I must have missed this
documentation.

> Address endpoints can timeout if responses fail to arrive at Synapse
by a > predefined timeout-duration specified in seconds. 
> The timeout action specifies whether to discard responses that arrives

> late, or to trigger a fault. Synapse has a periodic timeout handler
that
> triggers itself at each 15 second interval. Thus endpoint timeouts
will
> have a +/- error on actual trigger time. Though this can be minimized
by
> setting a System property "synapse.timeout_handler_interval" to a
> millisecond duration below the desired endpoint timeout, care must be 
> taken as a lesser value may have a higher overhead on the system. 

> An endpoint that fails may be suspended for a specified duration after
> such a failure, during which new messages will not be processed
through
> the endpoint. The 'suspendDurationOnFailure' could specify an optional
> value in seconds for which this endpoint should be suspended. 


> Since your timeout is < 15s, it will not be detected with the
"default"
> timeout detection of 15s.
I wasn't aware of this listener. Now I understand the behaviour.

> So for your case, you will need to run the timeout detector every
500ms or > so.. but in real life, I would assume you don't really want
to do this
> every 500ms, but rather every 5s or so..
Hmm, currently some service clients use timeouts of 2000 ms. We have a
lot of very lightweight services, which deliver results in a few ms ( <
100ms), if the operate normally. That's why a relatively low timeout is
quite "normal" for our use cases. Would it have such a negative impact
to specify values below 5 seconds for the check of the timeout handler?
In out case, would you suggest not to use the central ESB timeout
feature, but rather implement the timeout on the client side?
The big advantage I have seen of having information about services which
do not behave well in a central location would be that all other clients
would not have to figure this out on their own (walk right into the same
trap). The loadbalancing feature of the ESB should be able to exclude
this endpoint for a configurable amount of time. I guess this is what is
meant by "suspendDurationOnFailure".



> I think the above explanation would help understand the issue.. 
> you can edit the webapp/WEB-INF/classes/conf/wrapper.conf and add 
> a new line like shown below and restart the ESB..
> wrapper.java.additional.13=-Dsynapse.timeout_handler_interval=5000
Maybe I should try testing the listener with 1000 ms and see how it will
influence the system or is this just silly and I do not need to
investigate?


>> Besides this problem I would like to know if it would be possible, 
>> that a SOAP client could specify a timeout value in a custom SOAP 
>> header field in order to overwrite the ESB configuration of a 
>> particular endpoint timeout. A timeout on endpoint basis seems to 
>> be too inflexible. Even if it would be possible to define it on 
>> the level of proxy services (which currently only seems to be the 
>> case if I use anonymous endpoints) I would have to define multiple 
>> instances of a proxy service (which would only differ in their 
>> timeout definition) to account for different client requirements.
> This cannot be done right now.. but it is possible to support this.. 
> a new JIRA :-) ?
Yeah, this somehow depends on the answer to the above question. If such
small timeouts does not make any sense in terms of resource overhead, we
wouldn't need this feature as well. But if there is a way to implement
it without a big negative impact on the overall system, it would be good
if one could additionally specify a timeout on a loadbalancing group
and/or proxy level (as most of the time it would not make much sense to
specify it differently for each endpoint) as well as let the client
determine a useful timeout. In this case I would be happy to add a new
JIRA for this.

Regards,
   Eric

_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user

Reply via email to