a4j:queue. The next round.

[sergeysmirnov]

Pete, Jay,

during the prototyping of the queue we met some issues that need to be resolved to go any further. However, before we are digging into details, we would like to clarify point to be sure we are on the same page with you.

We suggest, that there are two and only two motivation to having a queue:

1. Eliminating the possibility of collisions when several JSF requests pass the JSF lifecycle at the same time. The queue prevents sending such requests. Only one request is processed. The rest ones are waiting.

2. Reducing the traffic between browser and the server. The "similar" requests came within requestDelay are absorbed. Only the last one is actually sent. Reducing the number of request reduces the server load.


Are you agree with the statement above or any other reason for a4j:queue exists?

[pmuir]

I agree.

[jbalunas]

I agree, but would add that the new queue mechanism is important to allow for a greater amount of "unrelated" asynchronous requests to processed.

The core of the problem is a flood of "similar" requests that choke up JSF/Seam. We need to be sure that we allow unrelated requests to still processed and sent Asynchronously or we loose the "A" in AJAX ;-)

This is accomplished by the different named queues - which should be maintained.

-Jay

[sergeysmirnov]

I agree.

Attaching queue to the form, but not to the whole view, disallows the reason #1. Pete could you explain why you insist to attach queue to the form?

[pmuir]

"SergeySmirnov" wrote:

I agree.

Attaching queue to the form, but not to the whole view, disallows the reason #1. Pete could you explain why you insist to attach queue to the form?

Actually I would replace the word "eliminating" with the word "reducing" for point 1.

I think this is compatibile with #1

[sergeysmirnov]

Pete, you know better that anybody that Seam is not multi-thread safety. Queues attached to forms will cause exceptions and mismatched the conversation scope data. Seam's user must have only one form per view to avoid the problem. Or they must to define the queue name explicitly for each ajax components on the page.

"default" should be most optional solution. However, query attached to the form by default is just a dangerous solution, because it presumes application server failures.

[pmuir]

First, let's be clear. Seam *is* threadsafe, it's just that the conversations don't support concurrent requests. Further, it's easy now in Seam to just "ignore" such problems (very useful when you are just using Ajax for outputting information e.g. validaiton).

I still think we need a way to specify a queue that is less granular than a page and more granular than a control.

[jbalunas]

I certainly think that we need to have a way to define a queue for a "part" of a page - preferably form based. In this case we would have control, page, and form scopes.

Is there a specific technical reason this will not work? Have you ran into an issue with doing this? Perhaps we can discuss work arounds to the issue if you have.

-Jay

[sergeysmirnov]

I do not see any strong objections against allowing queue for the "part" of the page. The question right now is only about implicitly created queues.

There are two statements:
1. Any ajax request belong to particular form (It is just a form submission using the XHR)
2. Forms cannot be nested.

Based on those statements if form has a queue implicitly, developer must explicitly declare the queue name as an attribute for each of the ajax components on the page. No other way to have one common pipeline between browser and server.

So, my suggestion is to avoid creating the queue for a form implicitly. I see two possible ways to declare the queue for all ajax components inside the form.
First, to declare a named queue anywhere on the view and use the "for" attribute of it to point to the form id.

...
<a4j:queue name="foo" for="bar" ....... />
 ...
 <h:form id="bar" .....>
 ....
 </h:form>
...

Second, to declare a unnamed queue as a child of form. I.e.

....
<h:form>
 <a4j:queue ..... />
 ...
</h:form>
...

Which way is preferable?

WDYT?

[pmuir]

Definitely, I don't want an implicit queue for the form. This is something you should turn on using the tag like your option 2.

[ilya_shaikovsky]

We no not restrict queue within form only. This just not a default.

1) queue for all the view created by default. So if no queues defined within the page at all - common view queue used.

2) queue defined outside any forms with special name e.g. ("org.RF.global") allows to difne this global form explicitly and modify its params.

3) In the same time we allow to register queue which used within concrete form only. So, queue defined inside a form - used by all the components inside this concrete form.

4) if the user wanted to use queue within some set of components he should define the queue name and point the components to this queue using this name as it designed now.


If this ok.. Or I missed some your points?

[pmuir]

"ilya_shaikovsky" wrote:
We no not restrict queue within form only. This just not a default.

1) queue for all the view created by default. So if no queues defined within the page at all - common view queue used.

But you can turn this off somehow? I still think this should be off by default. And enableable through some programmatic switch as well in web.xml - that way we can turn it on just when Seam is in use.

2) queue defined outside any forms with special name e.g. ("org.RF.global") allows to difne this global form explicitly and modify its params.

Yup

3) In the same time we allow to register queue which used within concrete form only. So, queue defined inside a form - used by all the components inside this concrete form.

Yes, and you can specify parameters on this queue too right?

4) if the user wanted to use queue within some set of components he should define the queue name and point the components to this queue using this name as it designed now.

Yes.

[pmuir]

"ilya_shaikovsky" wrote:
We no not restrict queue within form only. This just not a default.

1) queue for all the view created by default. So if no queues defined within the page at all - common view queue used.

But you can turn this off somehow? I still think this should be off by default. And enableable through some programmatic switch as well in web.xml - that way we can turn it on just when Seam is in use.

Actually, this is a nice idea - can we have it so that you can enable a queue for a particular view optionally?

For example:

<ui:composition>
 <a:queue enabled="#{conversation.longRunning}" />
 ...
</ui:composition>

This way people can just switch on the queue if they are using a long running conversation (when you probably need one) but not if they aren't, when you don't need one. If we can enable this queue programatically, then for example we could offer an option in Seam that enables the queue whenever you are in an LRC (if not otherwise set).

WDYT?

[ilya_shaikovsky]

But you can turn this off somehow?

1) certainly as I've already mentioned in emails - default queue should be enabled in web.xml to be created.

Actually, this is a nice idea - can we have it so that you can enable a queue for a particular view optionally?

also yes.. we've already has two things which was described - we could use something like enabled attribute or just set size for queue to 0 which will means that queue disabled.

[jbalunas]

Regarding implicitly creating queues - I was not suggesting that we create any queue implicitly except for the global queue as discussed.

....
<h:form>
 <a4j:queue ..... />
 ...
</h:form>
...

I prefer this approach to the other. There is less risk of users assigning 2 queues to the same form. Here at least the queue needs to be nested, and it is easier to check during rendering.

For example:

<ui:composition>
 <a:queue enabled="#{conversation.longRunning}" />
 ...
</ui:composition>

I really like this idea and it is much clearer to users than having them set the size="0".

Regarding the global queue and enabling/disabling - I'm not sure what is the best way to go - should the web.xml take precedence over a specifically "enabled" global queue, or the other way around. In other words if a user have "global" queues turned off in the web.xml should a view be able to override that by setting "enabled=true" on a <a4j:queue name="org.rf.global">?

Regarding multiple enabled/disabled queues nested in forms - there should only be one "enabled" queue allowed per form. Users may want to define more than one queue and enable/disable programmaticly. If 2+ enabled queues are found for a single form an exception should be thrown during rendering.

Regarding "0" size queue I believe it is still a queue - and although limited in usefulness does provide a way for users to define attributes, settings, and callbacks for requests. We should not guess and limit the users options here. A queue with a size of zero is still a queue, and should be valid.