[jboss-user] [JBoss Seam] - Re: Problems using ajax validation in seam-gen

[vincent.latombe]

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.

"pete.muir at jboss.org" 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.

"pete.muir at jboss.org" 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.

"pete.muir at jboss.org" 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
"pete.muir at 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!")
  | 

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