Ajax, conversation and multiple requests..

[appendix]

Hi!

I'm having an entity bean ("personal") with some attributes, which I would like to edit through a view page - nothing special so to say.
But I'm getting some random

The conversation ended, timed out or was processing another request

JSF Messages while editing the page exhaustively.

I've used seam-gen to set up the project and everything is working well.

My issue arose after I decorated all the input fields on the edit view with s:decorate and do a re-render on "onblur" to get the field immediately validated and a warning right next to the field, if validation fails.

Let me examplify with the following fraction from personal.xhtml:

<s:decorate id="nameDecoration" template="/layout/edit.xhtml">
 <ui:define name="label">
 <h:outputText value="#{messages['newPersonal.label.accountName']}"/>
 </ui:define>
 <h:inputText id="name" required="true" value="#{personalHome.instance.accountName}">
 <a4j:support event="onblur" reRender="nameDecoration" />
 </h:inputText>
</s:decorate>

All other input fields (approximately 20 - just to do some stress test) for each attribute of the entity bean is alike (id and reRender attribute adjusted respectively).

When the page is displayed by the browser and a regular user is editing each field after another, not causing the onblur event being fired too quickly, everything is fine.

But consider a user, selecting the first input element with the mouse and then hitting (and continuously holding down) the "Tab" key on the keyboard, leading to onblur events being fired from each input element very quickly -> The quoted message will pop up and the user is redirected to the home view.

This behavior is definitely not what I'd like to see, so I'm asking myself, how to prevent this situation?

I've tried to put a

eventQueue="personalAjaxQueue"

on every a4j:support element, improving the situation, but randomly I'm still getting the described behavior.

Am I understanding the whole situation right, that the redirect is caused, because an AJAX request is fired and the old one is not completely processed (and it happens in the same conversation)?

Has anyone else seen this behavior on forms with many input fields?

Any suggestions?

Any help is greatly appreciated!

Best regards, Kurt

[reind]

i had this exact same problem. You can somewhat improve things by adding a delays or queues as you've done but it is not a good solution as the problem can still occur - just less frequently, or under more rare circumstances.

This can also occur if a user clicks on an a4j:commandButton too quickly.

I honestly don't know of a good solution to this problem, and it really does make using a4j + conversation scoped beans unappealing.

[damianharvey]

This is a known issue and is easily avoided.

Increase the value of your concurrent-request-timeout in your components.xml to a value that is suitable for your application. I've got mine set to 10000 meaning that I want all methods completed within 10 seconds.

If a method doesn't complete within this time *and* another method has been queued up behind it by Seam, then I will get the "Conversation ended" message.

Cheers,

Damian.

[appendix]

Hi,

thank you guys for your posts!
Actually section "6.9. Concurrent calls to conversational components" in the reference documentation really covers the topic in an excellent way.

But I think I don't fully understand, why this behavior can still occur if there is the same eventQueue set on all ajax request generating input fields on the page?
Shouldn't then only one ajax request be sent at the time, hence no concurrent calls on the conversational component and no need for Seam to serialize them.

Also I wonder if there is a way to simply ignore (not even showing) the "Conversation ended" message.
If I'm getting it right, the worst that could happen is, that a validationMessage (coming from one of the many ajax request) is not properly displayed, but not this "Conversation ended" behavior.
Am I miss something here and simply ignoring is not a good idea anyway?


Cheers, Kurt

[pmuir]

There are still some improvements/"optimizations" to be made between Seam and RichFaces (and other Ajax frameworks) - I've got distracted by JBoss Embedded recently, but I've made the issue a blocker for 2.0.2.GA to address on the Seam side (we will probably need a release of RichFaces as well)

http://jira.jboss.com/jira/browse/JBSEAM-1832

[pmuir]

You are right - chucking you out of the conversation just because you're ajax request took to long isn't nice - we plan to make it possible to just drop requests (perhaps by default, but probably not by default until Seam 2.1).

[appendix]

Hi!

Pete, thank you very much!
I'm really appreciating getting help pretty fast on this forum most of the times.

Best regards, Kurt