ajax queues: Why not always on?

[luxspes]

Hi!
I am having a hard time dealing with a (but this is not a Seam question):

Caused by: org.jboss.seam.core.LockTimeoutException: could not acquire lock on @Synchronized component: xxxxxx

and a pretty common recommendation I find in the forums is to use: < a4j:queue >

Now, here is my question... why do I have to do that? why a queue is not used automatically always "by-design"? why do I need to worry about using it? why it is not transparent? (I mean those guys doing AJAX using plain XMLHttpRequest and jsp pages that return XML documents do not seem to need to worry about using queues... why do we need to?)

I mean, if I my pages are basically

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
 template="/layout/template.xhtml">
<ui:define name="body">
</ui:define>
</ui:composition>

And I am going to have to define a queue in template.xhtml and automatically have in available for all my pages, and I going to have to use one pretty much always, for all richfaces controls.... well, why it is not automatically always used and provided by design? (Or am i not understanding queues correctly?)

I mean, I can understand that maybe tweaking the queues can give me better performance, but for now, I just want it to to work, maybe slowly, but without crashing

And also... if I am working with 3.2.2... does that pretty much mean that avoiding this kind of syncronization problems is impossible without upgrading to 3.3.0 ?

[luxspes]

In the docs says that:

"The global default queue is disabled by default, because artificial serializing of all Ajax requests on a page can significantly affect expected behavior. "

What exactly does that mean? (because to me, it seems like having an automatically enabled global queue always would solve all this overcomplexity problem)

[luxspes]

And so RF-7755 is created.

[ilya_shaikovsky]

actually just set the web.xml param to turn it on for all the application.

[jbalunas]

Hi Luxspes, we have have been really busy working RF 3.3.2.CR1 and RF 4.0 ALPHA1 so we have not been able to get back to you.

The reason queues are not "on" all the time is that it would take the "Asynchronous" out of AJAX. All of a sudden all ajax requests would be serialized/synchronous instead of firing when called and returning as jobs finish on the server.

In some situations with Seam (JSF in general really) asynchronous requests can cause problems if requests are received out of order or while other requests are processing.

As Ilya said it is easy to turn the on automatically and on every view following the instructions for the web.xml param.

Hope this helps.

[luxspes]

Hi Luxspes, we have have been really busy working RF 3.3.2.CR1 and RF 4.0 ALPHA1 so we have not been able to get back to you.

I cant wait to download RF 3.3.2.GA! (and of couse RF 4.0 when it is ready)

The reason queues are not "on" all the time is that it would take the "Asynchronous" out of AJAX. All of a sudden all ajax requests would be serialized/synchronous instead of firing when called and returning as jobs finish on the server.

Is that accurate?,because if it actually changed AJAX in to SJAX it would block the browser (and AFAIK it does not do that).

In some situations with Seam (JSF in general really) asynchronous requests can cause problems if requests are received out of order or while other requests are processing.

It really really would be great if you could give me a concrete example of something "weird" that could happen by using the global queue

As Ilya said it is easy to turn the on automatically and on every view following the instructions for the web.xml param.

Hope this helps.

Yes, it does (but a concrete example would be better).

[ilya_shaikovsky]

Is that accurate?,because if it actually changed AJAX in to SJAX it would block the browser (and AFAIK it does not do that).

RichFaces queue highly customizable and has features of combining similar requests, aborting out-of-date page responce, dropping older ones if queue size exceeded and so on, so actually it will not block the browser. But it's enablement will really make all the events wait for another.

It really really would be great if you could give me a concrete example of something "weird" that could happen by using the global queue

Jay talked in his comment not about requests that using global queue but about ones which not using ;)