Rapidly clicking A4J links/buttons crashes Seam

[m4rk]

I've been running into an issue that is consistently showing up across our entire application where ever we are using A4J. If you rapidly click on an A4J command link or button a bunch of times, after around the 6th or 8th click, I end up with a null pointer exception which is caused by the controller's binding's not being recognized when accessed in the xhtml.

I explored a couple options first, specifically two A4J attributes:

- ignoreDupResponses
- eventsQueue

These were culled from this thread: http://jboss.com/index.html?module=bb&op=viewtopic&t=105766

Neither of these suppressed my requests sufficiently or prevented my seam controller from being deserialized each time a request was sent. Eventually it seems that when trying to rerender the 5th or 6th request, the controller instance hasn't been established yet for that request and I end up with an NPE. For the former attribute, I just set it to true. For the latter, I just gave it an arbitrary hard coded string attribute (which I am assuming would need to be unique for each A4J link).

Is there a way we can globally prevent requests from processing from a particular A4J link until it's finished with any existing requests? Am I using eventsQueue incorrectly? We are exploring a short term solution of disabling the onclick of the element utilizing A4J while its processing and restoring upon completion via Javascript. Is there a bug in Seam that would help explain why the controller's not initializing in time? Perhaps it should block A4J request processing until the controller's ready. Big thanks in advance for any of your help.

-Mark

[sergeysmirnov]

ignoreDupResponses does not make sense for the server behaviour.

do not forget to define the id explicitly for ajax components and components that add namespace to the ids

[m4rk]

We are doing that. And even if they were not explicitly defined, clicking on the links rapidly is sending back the exact same request data, just repeatedly, regardless of how the id's were generated. Should these not be blocked if I'm using ignoreDupResponses?

[sergeysmirnov]

ignoreDupResponses ignores the response when it comes back to the client. It cannot help Seam to be more thread-safety that it is.

[m4rk]

Good point. I need something called "ignoreDupRequests" :-D

[sergeysmirnov]

"m4rk" wrote:
Good point. I need something called "ignoreDupRequests" :-D

This is out of scope for RichFaces to kill Application Server threads or create a transactional feature over it.

[m4rk]

I will post this to the JBoss Seam forum. Thanks for your help, Sergey.