Much easier solution for those of us facing issues where periods of high activity lead to timeouts. I would have to suggest a configurable value would at least allow for a temporary band aid, in lieu of diving in and changing how the BPEL in an already existing project is working. Just my 2 cents... Im curious as to what ended up being the solution here? TIA
Lavanya Ramakrishnan wrote: > >> The message exchange timeout is not configurable but it's also 2mn, which >> is >> fairly conservative. At this point I'm wondering if timing out is not the >> correct behavior. Maybe there's a use case that I'm not seeing but beside >> pushing load testing at its max, I can't see when you'd want to wait for >> more than 2mn for a non-reliable transport over a request/response >> exchange. >> Don't you think? > > In terms of semantics, I am not sure if at this point timing out is the > correct behavior either in this situation. But I can see that as a > possible approach for sure. I think some of it goes to where you want to > put the fault tolerance for excessive delayed response times. > > I guess it is true that excessive load might be the only case when we need > longer timeouts. I guess otherwise clients can also use async response as > a way for longer response times or variable response times from individual > services. > > My concern was largely that with slightly complex workflows I might start > seeing this even with lesser concurrent clients but I can probably > experiment to find out if this is true. And I can probably tweak the value > in code directly for when I am doing experiments with larger number of > clients for now. > > thanks! > Lavanya > > -- View this message in context: http://www.nabble.com/Problem-with-multiple-concurrent-clients-tf4884888.html#a14140278 Sent from the Apache Ode User mailing list archive at Nabble.com.
