"vincent.latombe" wrote : And does this timeout represents the amount of time the call must wait before failing, or is it the amount of time we estimate this call should take? IMO These two metrics aren't independent. I think the timeout needs to be set to n * timeout + m, where n & m need to be determined through experiment. In essence I think the timeout needs to be set to somewhat longer than the expected time the method will take to execute. "vincent.latombe" wrote : I think the second option is better. A method should declare how much time it typically takes to execute, so that if a new call occurs, it can wait for this time. By extension, if we have n calls waiting and we've got a n+1-th call coming, this new call must take into consideration all timeouts defined by previous calls and sum them up, to determine the amount of time it should wait. Ok, interesting. I'm not entirely sure I see the benefit of this as it doesn't cancel requests that are taking too long to execute. I can see two scenarios: 1) We have the same method (e.g. Damien's example of a total being calculated) for which it doesn't matter if it isn't called every being called many many times. In this case I would think something like: Request 1 -> getTotal is processed for > concurrentRequestTimeout Request 2 -> gets dropped Request 3 -> gets processed Request 4 -> gets dropped Request 5 -> gets dropped Request 6 -> gets processd would be ideal - just some of the requests are processed (this is what currently happens) 2) We have a method which we must execute every time. In this case executing the method asynchronously and polling for a result from the page would be a better approach IMO. anonymous wrote : "pete.muir(a)jboss.org" wrote : 4) Make it easier to disable the warning message on a per request basis - it really means one thing if your conversation times out as you were idle (in this case you want something like "Sorry, you were idle too long and your workspace has been lost") and something completely different if you have a concurrent request timeout ("Sorry, you are swamping the server, please slow down!") | | | That would be a plus, but it shouldn't be necessary if the timeout handling works correctly | Ok, but I don't think we're ever going to reach a magic point where this just works ootb (short of just serializing all requests into a queue of infinite length with no timeouts). And even when you're concurrent requests working nicely, you may still have some outside factor (e.g. server has heavy load from another process) which causes your concurrent calls to not be executed within the timeout and you may or may not want to notify the user of this. "damienharvey" wrote : As you say in option 3, something like ignoreDupRequests would be handy, but sometimes you may well want the behaviour that Vincent has coded - ie. I want all of my requests to be processed eventually (within reason). Mind you I suppose that could be accomplished with a very long timeout... Yes, exactly. "damienharvey" wrote : What are the downsides of increasing this timeout? For instance what is the danger in setting it to a stupidly large number (perhaps equal to the conversation timeout)? That if you have a very long running method that is called many times by ajax it may consume much of your processing power, and not timeout. This is why I think you need a sensible default, with the option of increasing it on a per method basis. anonymous wrote : When the period times out it doesn't just abort the call, it ends the conversation . If you compare a Conversation to a Session, you wouldn't expect a Session to expire just because a page couldn't load. AFAICS it doesn't *end* the conversation, it just kicks you out of it and into another (temporary) conversation - so the previous conversation is still there, but not active. I agree, this isn't very friendly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080796#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...