Specifically the problem I'm concerned about here is that seam-gen generates a:support with onblur which breaks as described in the forum thread.

I am seeing a similar issue, but mine results in a NPE.
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4076331#4076331

It has something to do with <rich:panel> (don't know about all other panel types), when I switch to use <rich:tabPanel> and <rich:tab>, there is no problem.
The page is reloaded onblur from the field, but data is lost - not updated in object or display on screen.
Maybe not Seam problem at all.

I am not so sure, because, as I wrote in the forum, with this code (without panel) I got the same error:

         <a:form ajaxSubmit="true" id="formAC">
         <h:outputText value="Tipologia: "></h:outputText>
                <h:selectOneMenu id="tipologiaAC" value="#{articoloHelper.tipologiaArticoloDaCollegare}">
                 <s:selectItems value="#{tipologiaArticoloAll.resultList}" var="tip" label="#{tip.descrizione}" noSelectionLabel="Seleziona la tipologia..."/>
     <s:convertEntity />
     <a:support event="onchange" reRender="articoliACop" ajaxSingle="true">
     </a:support>
                </h:selectOneMenu>
<a:outputPanel id="articoliACop">
<h:outputText value="Oggetto da collegare: " rendered="#{articoloHelper.tipologiaArticoloDaCollegare!=null}"></h:outputText>
                <h:selectOneMenu id="articoliAC" value="#{articoloHelper.articoloDaCollegare}" rendered="#{articoloHelper.tipologiaArticoloDaCollegare!=null}">
                 <s:selectItems value="#{articoloHelper.articoliCollegabili}" var="tip" label="#{tip.titolo}" noSelectionLabel="Seleziona un oggetto..."/>
     <s:convertEntity />
     <a:support event="onchange" reRender="btnACop" ajaxSingle="true"></a:support>
                </h:selectOneMenu>
                </a:outputPanel>
                <a:outputPanel id="btnACop">
<a:commandButton id="btnAC" value="Collega" action="#{articoloHelper.collegaArticolo(articoloHome.instance)}"
rendered="#{articoloHelper.articoloDaCollegare!=null}" reRender="opArticoliCollegati"></a:commandButton>
</a:outputPanel>
<a:status startText="Aggiornamento dati in corso..."></a:status>
         </a:form>

I am getting the same issue on Seam 1.2.1.GA. It happens regularly during normal operation, but I can simulate it by holding in the tab key for 2-3 seconds (quickly tabbing between fields) and then immediately clicking the submit button. To try and work around it, I have changed my a:support tags from...

<a:support event="onblur" reRender="learningGradeDecoration">

... to ...

<a:support event="onblur" bypassUpdates="true" ignoreDupResponses="true" reRender="learningGradeDecoration">
  <s:conversationId/>
</a:support>

This did not work. In the process I discovered another issue though. When tabbing through the input fields quite quickly, sometimes the following exception is thown:


09:39:08,203 ERROR [ExceptionFilter] exception root cause
java.lang.IllegalArgumentException: Value binding '#{examPeriodCrud.item.allowedExamMonths}'of UISelectItems with component-path {Component-Path : [Class: org.ajax4jsf.framework.ajax.AjaxViewRoot,ViewId: /restricted/exam_periods/beginAdd.xhtml][Class: org.jboss.seam.ui.UIDecorate,Id: _id84][Class: javax.faces.component.html.HtmlForm,Id: form][Class: org.jboss.seam.ui.UIDecorate,Id: examMonthDecoration][Class: org.jboss.seam.ui.UIValidateAll,Id: _id130][Class: javax.faces.component.html.HtmlSelectOneMenu,Id: examMonth][Class: org.jboss.seam.ui.UISelectItems,Id: _id131]} does not reference an Object of type SelectItem, SelectItem[], Collection or Map but of type : null
at org.apache.myfaces.shared_impl.util.SelectItemsIterator.hasNext(SelectItemsIterator.java:141)
at org.apache.myfaces.shared_impl.renderkit.RendererUtils.internalGetSelectItemList(RendererUtils.java:477)
at org.apache.myfaces.shared_impl.renderkit.RendererUtils.getSelectItemList(RendererUtils.java:453)
at org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:278)
at org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderMenu(HtmlRendererUtils.java:252)
at org.apache.myfaces.shared_impl.renderkit.html.HtmlMenuRendererBase.encodeEnd(HtmlMenuRendererBase.java:54)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at org.jboss.seam.ui.JSF.renderChild(JSF.java:180)
at org.jboss.seam.ui.JSF.renderChildren(JSF.java:162)
at org.jboss.seam.ui.JSF.renderChild(JSF.java:178)
at org.jboss.seam.ui.JSF.renderChildren(JSF.java:162)
at org.jboss.seam.ui.UIDecorate.encodeChildren(UIDecorate.java:234)
at org.ajax4jsf.framework.renderer.RendererBase.renderChild(RendererBase.java:282)
at org.ajax4jsf.framework.renderer.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:159)
at org.ajax4jsf.framework.renderer.AjaxChildrenRenderer.encodeAjaxChildren(AjaxChildrenRenderer.java:97)
at org.ajax4jsf.framework.renderer.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:150)
at org.ajax4jsf.framework.renderer.AjaxChildrenRenderer.encodeAjaxChildren(AjaxChildrenRenderer.java:97)
at org.ajax4jsf.framework.renderer.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:150)
at org.ajax4jsf.framework.renderer.AjaxChildrenRenderer.encodeAjaxChildren(AjaxChildrenRenderer.java:97)
at org.ajax4jsf.framework.renderer.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:150)
at org.ajax4jsf.framework.renderer.AjaxContainerRenderer.encodeAjax(AjaxContainerRenderer.java:125)

Please! does anybody have any workaround for this issue other then not using AJAX validations???

By the way, the tags the selectOneMenu fields mentioned in my previous comment are structured in the following way.


    <s:decorate id="learningGradeDecoration" template="/layout/_edit.xhtml">
      <ui:define name="label">Learning Grade:</ui:define>
      <h:selectOneMenu id="learningGrade" value="#{examPeriodCrud.item.learningGrade}" required="true">
        <s:selectItems value="#{learningGradeFinder.all}" var="learningGrade" label="#{learningGrade}" />
        <s:convertEntity />
        <a:support event="onblur" bypassUpdates="true" ignoreDupResponses="true" reRender="learningGradeDecoration">
   <s:conversationId/>
   </a:support>
      </h:selectOneMenu>
    </s:decorate>

Vincent, I've generated a simple app using seam-gen, but I can't reproduce using your instructions. Please attach a seam-gen'd add built against head without the lib directory to this issue, and provide step-by-step instructions to reproduce. If you modify the seam-gen app at all please say what modifications you make. Also, what browser are you using?

John Gilbert: you are, as you say seeing a different problem. Please discuss it on the forum or a different issue (I will look at your thread in a minute)

Tim: this issue has nothing to do with rich:panel

Demetrio Filocamo: Again a different issue, you seem to have selectXXX menus in there and no s:validate's

Charl Fourie: You aren't using the same version of Seam as Vincent so this is another problem. You need to discuss this on the forum

Sorry to jump in but I've been watching this as I had similar behaviour and am keen for resolution. I can't recreate this problem with Seam from the nightly builds.

Looks fixed.

It's still very easy to cause the conversation to be ditched by tabbing through fields quickly if they are all ajax4jsf enabled - especially if they do some work on the backend (eg. with an action). The ajax4jsf guys have suggested a number of ways to avoid this including timeout, eventQueue, ignoreDupResponses etc. which all help. Also using onchange rather than onblur is useful.

Cheers,

Damian.

Unit testing for this bug. Create a new Hello, input something in the field and hit Save without focusing out the text field. It should show "The conversation ended, timed out or was processing another request" message. No error message in Jboss log.

Here is something interesting.... I've been testing so far on Firefox and still got the problem. I just tried on IE7 and I haven't managed to reproduce the bug because IE seems to wait for the ajax call to respond before submitting the form.

Vincent, I can't reproduce on CVS head (using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6) - are you using CVS?

Damien, if you can provide details to reproduce the behaviour then please do so :)

I think that adding eventQueue and requestDelay and ignoreDupResponses to a:support in a Seam-gen app is probably a good idea.

As mentioned as I can't reproduce the validation error. That appears to be fixed.

I can reproduce the "flood" error. I've put the code into the forum post. I'll also post to ajax4jsf forum pointing them to this.

I am still *very* concerned about the stability of ajax4jsf. I realise that this is the wrong place for this but it impacts Seam now that you're all one happy family. If I specify an eventsQueue I would expect that the ajax4jsf handler would never have to blow away the conversation. It should just process them in order discarding when appropriate (eg. based on dups or timeouts).

Cheers,

Damian.

Pete : affirmative, i'm using CVS head.
I think the problem is less likely to happen on a fast machine since it has to do with speed of ajax response.
Here are 2 scenarios :
- Client : ajax event -> Server
- Server : ajax response -> Client
- Client : submit -> Server
- Server : insert.... -> Client

This scenario is OK

Here is my scenario which fails

- Client : ajax event -> Server
- Client : submit -> Server
- Server : error -> Client

So if submit happens before ajax response the error happens. If the server is slow the time between ajax event and response will increase so as the time frame in which the error is likely to happen.

And the "flood" error has same origin, as you decrease time between to ajax calls, you're more likely getting the error.

Ok, yes, I have a fast computer ;)

I'll try to work with the code Damien has posted.

In many ways we are on the wrong JIRA/issue here, so lets keep this one open as a way of suggesting enhancements to seam-gen's generated pages to handle this situation (as Damien suggested above) and use the forum to discuss the problem in general.

Here is a patch for modifications i talk about on thread. Successives calls inside a conversation are executed serially because of exclusive locking of the conversation.

Vincent, thanks for the patch.

Pete, can you confirm that you get the same issue when inside a conversation? And is Vincent's solution one that you think will make it into the code-base? (if so, I'll start using it soon as this will resolve a lot of the instability in my ajax-heavy Seam app).

Cheers,

Damian.

Slipping as need to discuss this in more detail. Improved docs should help for now.

My conclusions are:
   - something like dropTimedOutRequests="true" in RichFaces as an option for requestDelay
   - when non-ajax request occurs on a view, cancel all Ajax events (waiting for return?) and then do submit (this in RF)
   - Seam needs to know the difference between concurrent timeouts and conversation timeout (diff warning)
   - Granularity of conccurent request control (pages.xml?)
   - More leniency from Seam when concurrent requests occur - perhaps (default?) of dropping concurrent timeout requests. Options are to drop the conversation (eugh, current behviour), drop the request, or to process the request in a temp context but to then return to the correct context later (odd)

I know that (as stated above) I am using an older version of Seam, but the work-around that worked for me will also be applicable to Seam2 and can therefore be helpfull. The following work-around fixed my problems:

In components.xml, set the concurrent-request-timeout to something high like 10000 (10 seconds)

<core:manager concurrent-request-timeout="10000"
conversation-timeout="120000" conversation-id-parameter="cid"
conversation-is-long-running-parameter="clr" />

I also found that any lists used to populate list boxes should be cashed in the page context to prevent SQL queries from executing every time a list box looses focus (should be done anyway)

Hope this helps.

Slipping as more discussion is needed than can be done before 2.0.0.GA release.

As discussed in the Big Lots Case Study, this is probably the biggest issue we have. We were using Seam 1.2.1.GA. No matter what combination of A4J and Seam configuration we had, we could not get rid of the issue. For example, on one screen with an onblur event we tell the users to explicitely hit tab to ensure that the screen is kosher before they hit the Save button.

We tried using the eventQueue, requestDelay, ignoreDupResponses as well as the Seam conversation timeout and @Synchronized with a timeout. We got so frustrated with this behavior that we wrote our own event queue widget to alleviate the problem.

Keith, are your slides up somewhere? I'm interested in the problems you encountered and what you did to fix it.

I believe we've also hit this bug.

We're also using a4j:support on a field, and when typing fast in there, we get kicked out of the session.

A look at the HTTP header log shows that at one point we get two successive responses from the server: the first one is a legit AJAX reply, the second is a redirect because of a missing conversation.

Turns out we can reproduce the very same bug when clicking several times on a4j:commandLink. So this is a fairly generic bug w.r.t a4j/seam.