Pete: thanks for your explanations, I think I have a clear and complete
understanding of the situation now. See my comments inline.
Now, my parallel processing stuff is a bit rusty, but looking at ReentrantLock,
and at Vincent's patch, I think it, is the equivalent of setting an infinitely
long concurrentRequestTimeout - so that requests are delayed indefinitely until
they can be scheduled.
It is exactly what I intended to do.
"[EMAIL PROTECTED]" wrote :
| So - what can we do to make this better?
|
| 1) Document this (much) better based on discussions in this thread
|
That would be a good stard. But even with better documentation, there is a need
for a better control of these timeout problems.
"[EMAIL PROTECTED]" wrote :
| 2) Make it easier to set the concurrentRequestTimeout on an action by
action basis e.g.
|
| @ConcurentRequestTime(5000)
| | public void doSomething() {}
|
It's interesting, but won't really solve the flooding problem. As far as I
understood the code, the timeout is constant, not depending on the number of
calls waiting for conversation lock. 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?
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.
"[EMAIL PROTECTED]" wrote :
| 3) Provide something equivalent to ignoreDupRequests (so that multiple
concurrent calls to the same method can be discarded).
|
That would be great too to prevent flooding cases more easily
"[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!")
|
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080721#4080721
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080721
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
