JBossDeveloper

Damien: yes, I can reproduce.

I don't think Vincent's patch will make it into Seam. Currently Seam serializes concurrent requests to Conversational scoped beans (failing if it has to wait longer that the concurrent-request-timeout).

Vincent's patch (afaics) alters this to allow concurrent access to conversational scoped beans (which IIRC will fail when accessing SFSBs) - though I'm not sure of Vincent's exact intention as he says he is serializing calls to getTotal - but I think he is actually parallelizing calls.

I need to spend some time looking at this part of Seam (I'm not overly familiar with it) and talk to Seam/Richfaces dev on this.

Thanks Pete. Nice to know that it's on the radar and even nicer to have this finally pinned down to a reproducible bug.

Cheers,

Damian.

Maybe it needs a similar mechanism to the eventsQueue used by ajax4jsf (ironically).

Vincent, yes, I understand your patch better now :) So, I want to understand better what you guys *want* the behaviour to be.

I've attempted to summarise the current behaviour:

Each received ajax request is processed by Seam in serial. If concurrent calls occur, Seam queues the action event for a period of time (the concurrent request timeout), if it can't process the event within that period it aborts the call and prints out a FacesMessage telling us this. You can adjust the concurrent request timeout globally (through components.xml) or on a request by request basis (through Manager.instance().setConcurrentRequestTimeout();) - and obviously you can queue etc. events on the client side through a4j.

So, Seam has the equivalent of both eventsQueue (always on) and requestDelay (perhaps hard to set on a request by request basis), it doesn't have an equivalent of ignoreDupRequests.

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.

So - what can we do to make this better?

1) Document this (much) better based on discussions in this thread

2) Make it easier to set the concurrentRequestTimeout on an action by action basis e.g.

@ConcurentRequestTime(5000)
public void doSomething() {}

Vincent said.

The issue comes from the fact that when I hit the Save button, the onblur event from a:support fires at the same time and it breaks the save process. If I click outside the edited field, and then click the save button it works.

<a:support event="onblur" reRender="cityNameDecoration" bypassUpdates="true" onsubmit="this.getElement('0').focus();"/>

Pete said:

If concurrent calls occur, Seam queues the action event for a period of time (the concurrent request timeout), if it can't process the event within that period it aborts the call and prints out a FacesMessage telling us this.

"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?

"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.

"pete.muir@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

"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...

"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)?

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.

Damien, removing the ignoreDupRequests attribute from a:support makes our test case work - this is actually seriously breaking Seam's conversation handling currently as it attempts to abort the current request and sends the next. Unfortunately request isn't aborted. I'll look into why.

I've added some docs

http://fisheye.jboss.org/browse/JBoss/jboss-seam/doc/reference/en/modules/conversations.xml?r1=1.34&r2=1.35

I'll look at the onblur/submit case next.

Vincent, I've managed to work around the onblur/submit problem like this:

<s:decorate id="thirdDecoration" template="layout/edit.xhtml">
 <ui:define name="label">Third</ui:define>
 <h:inputText id="third"
 required="true"
 value="#{calcBean.third}">
 <a:support event="onblur" reRender="thirdDecoration, total" eventsQueue="calc" />
 </h:inputText>
</s:decorate>

<a:commandButton action="#{calcBean.save}" eventsQueue="calc" value="Save" />

I'm a bit late to this party, but we have been experiencing this for months. We originally tried the same technique Pete suggested using - a4j eventqueues with requestDelays - but it didn't go far enough.

What we wanted was if a user was typing or clicking, to send one request to the queue requestDelay milliseconds after the final generated event on that queue. This would allow a user to click a button repeatedly, but only the very last button click would be processed. Or if a user went trigger happy on the keyboard in an input field with a keypress event, it would only react on the last keypress event. Or we could send an input field onchange and a button click through the queue to send only the last event. There is a chance for lost javascript events, but since 99.9% of our pages simply submit the form and kick off an action, ignoring the original events didn't really hurt anything.

In order to do this we implemented a special JavaScript event queue widget that enforced this behavior. It worked pretty well. However, we still get the "Conversation ended, timed out or was processing another request" message so often that our users consistently bring it up as a problem. We would still love to see JBSEAM-1832 implemented since it helps to address the double click problem as well as the ""The conversation ended, timed out or was processing another request" problem.