"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 : "[EMAIL PROTECTED]" 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#4080796
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080796
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
