-
15. Re: a4j:queue. The next round.
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">?
And again fully agree. I've meant that param should be like org.richfaces.CREATE_QUEUE_BY_DEFAULT. and should control if the queue will be created if not defined. If it's false but user created the queue at view - it will be created for the view.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.
Hm.. Look I think we should allow onle one so called special queue. I mean for example queue with no name inside a form or with special name - will become global for this form. Two components without name or with special one should throws exception. But named queues could be created also in the same form. This queues will be used only by components which defines this queue in eventQueue attribute. -
16. Re: a4j:queue. The next round.
"ilya_shaikovsky" wrote:
And again fully agree. I've meant that param should be like org.richfaces.CREATE_QUEUE_BY_DEFAULT....
good - but I would suggest adding "global" to the param to be clear - org.richfaces.ENABLE_GLOBAL_QUEUE
Hm.. Look I think we should allow onle one so called special queue. I mean for example queue with no name inside a form or with special name - will become global for this form. Two components without name or with special one should throws exception. But named queues could be created also in the same form. This queues will be used only by components which defines this queue in eventQueue attribute.
I think that we are basically in agreement here. Except that I think there should be only one enabled nested or "special no name" queue per form. It should be a fairly easy check to make during rendering. -
17. Re: a4j:queue. The next round.
so we agreed in last point.. I've meant the same.. Probably my explanation was not correct.
Let's get the names for the queues.. We provide some 'org.richfaces.global.queue' and 'org.richfaces.global.form.queue'. Also the user could define some queues with another names and use through attributes. anyway all queues should have unique names. -
18. Re: a4j:queue. The next round.
"ilya_shaikovsky" wrote:
Let's get the names for the queues.. We provide some 'org.richfaces.global.queue' and 'org.richfaces.global.form.queue'. Also the user could define some queues with another names and use through attributes. anyway all queues should have unique names.
Does the form queue need a name? If it does it will need to be named based on the form name/id because there may be more than one form on the page. -
19. Re: a4j:queue. The next round.
"jbalunas@redhat.com" wrote:
Does the form queue need a name? If it does it will need to be named based on the form name/id because there may be more than one form on the page.
If so, we could have more than one queue without a name defined.
My thought is to introduce two terms:
global queue - queue available globally from any place of the whole view
local queue - queue available locally within the form.
If local queue is defined, it overwrites the global queue.
One more thing - we still have a queue with names. The whole picture is:<f:view> ... ... <!-- global queue. I.e. global for the whole view --> <a4j:queue ...... /> <!-- global named queue. i.e. queue with name that can be referenced from any ajax components on the view --> <a4j:queue name="foo" /> ... <h:form> .... <!-- local queue. I.e. local for the particular form --> <a4j:queue ...... /> .... </h:form> <h:form> .... <!-- local queue. I.e. local for the particular form --> <a4j:queue ...... /> <!-- local named queue. i.e. queue with name that can be referenced from only ajax components of this form --> <a4j:queue name="foo" /> .... </h:form> ... </f:view>
For the sake of simplicity, I suggest eliminate the local named queue. I.e. if queue has a name, it is a global automatically (can be referenced within the whole view). As an alternative, we can disallow to define a named queue inside the form.
Do we really need a named queue or having view-based and form-based queues are enough? I see one strong reason - the backward compatibility. If developers group requests using eventsQueue attribute, it might be supported only when queue name will continue to be supported. -
20. Re: a4j:queue. The next round.
"pete.muir@jboss.org" wrote:
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.
I do not thing that the Application Server specific switch is a right way to go in general.
In most cases developers uses Ajax, the traffic is not tight (like clicking the button => partial page update). So, people just do not pay attention to this feature. However, people start to care about right after that have a occasional collisions of requests loss. Sometimes, it is very hard to realize that those occasional problems comes from missing a queue.
I am vote for turning a queue ON by default, because it will prevent such problems by default. In most cases (when the traffic is not tight), this changes nothing and people will continue to just do not care about it. -
21. Re: a4j:queue. The next round.
I do not thing that the Application Server specific switch is a right way to go in general.
No one has suggested an Application Server specific switch. In fact, read the post afterwards where I suggest making it a request specific switch.I am vote for turning a queue ON by default, because it will prevent such problems by default. In most cases (when the traffic is not tight), this changes nothing and people will continue to just do not care about it.
I am strongly against this. Asynchronous requests are a founding principle of Ajax frameworks. -
22. Re: a4j:queue. The next round.
"SergeySmirnov" wrote:
If local queue is defined, it overwrites the global queue.
I assume you mean is used instead of, not overwrites?For the sake of simplicity, I suggest eliminate the local named queue. I.e. if queue has a name, it is a global automatically (can be referenced within the whole view). As an alternative, we can disallow to define a named queue inside the form.
The only reason to support a named queue is to allow you to specify queue attributes once, and reference them elsewhere.
Actually, maybe we need a seperate tag for queue definition:<a:queueDefinition name="foo" ... />
<a:queue ref="foo" />
-
23. Re: a4j:queue. The next round.
"pete.muir@jboss.org" wrote:
I am vote for turning a queue ON by default, because it will prevent such problems by default. In most cases (when the traffic is not tight), this changes nothing and people will continue to just do not care about it.
I am strongly against this. Asynchronous requests are a founding principle of Ajax frameworks.
+1For the sake of simplicity, I suggest eliminate the local named queue. I.e. if queue has a name, it is a global automatically (can be referenced within the whole view). As an alternative, we can disallow to define a named queue inside the form.
I think we need named queues. It allows separation of requests as defined by the developer. This will allow a greater flow of unrelated asynchronous requests while giving the developer the tools to stabilize these requests when and how it is needed. Forcing these into 2 buckets could bottleneck the calls.Actually, maybe we need a seperate tag for queue definition:
<a:queueDefinition name="foo" ... />
I think we should wait and see how the queue is used, and let it vet in the community for while before adding another element, and aspect to this task. This is not a bad idea, I am just not sure of the need/requirement for it now. -
24. Re: a4j:queue. The next round.
Ok guys.. We've got all the points about queue definition and I'll summarize them in our RS document.
And now we want to ginve a more presice definition about some functionality points.
1) Events similarity
Similar events should be combined in order to reduce requests frequency and send only actual information to server.
By default we plan to use clientId of the components in order to mark requests from one co1mponent similar.
For example if you typing in the field with a4j:support defined. All the events will be comboned during request delay and only latest keypress request will be sent
In order to allow the developer to mark request from some different components as similar we plan to add new common attribute to the action components. This should be something like requestId(Draft name!). All the requests with similar requests id will be combined during request delay.
2) View Changes and requests waiting in queue
Imagine a situation when one request(from component A) sent and the other(from component B) waits in the queue. But after responce from A comes it reRenders part of page where the B component located. We plan to implement two features in order to reduce the glitches in such situations.
2.1) We will not collect the events in the queue only as it was before. We will generate the request info right after event and put the complete generated request to the queue. In this case actual form information will be sent with the request.
2.2) We plan to introduce one more common attribute which should allow to define the components which should reset the queue.
For example: we have a table with links in cells and pagginator for this table. All the components placed uses the same queue. In this case we definitly should specify something like resetQueueAfterRequest="true" on the pagginator control in order to restrict links submits from prevoius page after pagginator switched the table page.
3) Request delay
After request with some delay comes to queue(A) the counter for this request should be started. If similar request(e.g. from the same component - A') appears - these two requests should be combined(AA') and counter should be reseted.
In order to avoid queue freezing using this rule we should add one more rule. If some not similar request comes to the queue(B) - it placed after the first one(AA',B). And if the AA' request doesn't still leaved the queue but request similar to A appears again - these requests should not be combined with the first one but should be placed after B. (AA', B, A'').
Such behavoiur will allow us
3.1 to maximize similar requests mergence
3.2 to sent only latest fields state for similar requests
3.3 not to block the queue if the different types of requests comes to queue and should wait one for another.
And one more addition. Poll component will be defined as not delayable by default on the component level in order not use the queue delay(its own value for this param will redefine queue param) to avoid blocking periodical update in the queue. User will be able to redefine this for sure on the component level if need.
4) Priorities
We plan to introduce priorities which could be defined for any ajax action component using corresponding attribute. There should be three level of priorities "low", "normal" and "high". If the request with "high" priority comes to the queue it will be placed before all the requests with lover priorities. -
25. Re: a4j:queue. The next round.
"ilya_shaikovsky" wrote:
Ok guys.. We've got all the points about queue definition and I'll summarize them in our RS document.
I will be writing a wiki page for the queue design that may be similar to your RS document. I would prefer that we work with the wiki as it is more open to the community and easier to access. I may not be able to do this today because of partial PTO. I will post when it is completed. If you would like to start it that is fine, then I'll update as needed.
Basically we would like to see a wiki page that represents the current design decisions. This then links to forum topics for discussions of the open issues and planning. Then the wiki page gets updated as decisions are made.
In order to allow the developer to mark request from some different components as similar we plan to add new common attribute to the action components. This should be something like requestId(Draft name!). All the requests with similar requests id will be combined during request delay.
I like this idea! I was wondering how this calculation is done today with the duplicate request flag?
I'll add some more comments when I return.
Regards,
Jay -
-
27. Re: a4j:queue. The next round.
I just posted a major update to the wiki page. The update includes code examples of usage, and added some ideas and concepts from the other topics, and conversations.
http://www.jboss.org/community/docs/DOC-12894
Please let me know your thoughts, and comments. Also let me know if I missed some of the open issues. I believe we had discussed some of them, but no conclusions made.
Regards,
Jay -
28. Re: a4j:queue. The next round.
I tried to edit the document, but JBoss Wiki just wiped out (as usual) everything.
So, briefly:OPEN ISSUE: Pete and I do not think that individual elements should be able to override the queues settings. If they need different queue behavior they should use a different queue.
This automatically breaks the backward compatibility. In order to upgrade to the new version of RichFaces, developers have to remove all existing queue oriented attributes on the Ajax components pointing to one or several queues with eventsQueue attribute.
eventsQueue or eventQueue (like in the document) is just another dilemma - to have a backward compatibility or a right English in the name.
-
29. Re: a4j:queue. The next round.
The wiki is going through some planned maintenance atm - should be cleared up soon.
As for editing the wiki - I think we should keep the wiki to either agreed upon design decisions or listings of open issues. that way we will not cloud the wiki with discussions."SergeySmirnov" wrote:
OPEN ISSUE: Pete and I do not think that individual elements should be able to override the queues settings. If they need different queue behavior they should use a different queue.
This automatically breaks the backward compatibility. In order to upgrade to the new version of RichFaces, developers have to remove all existing queue oriented attributes on the Ajax components pointing to one or several queues with eventsQueue attribute.
Just so that I understand, in the current queue system when a component sets these values the new settings are attached to that specific event, and does not effect the base settings of the queue - correct? In the new system the queue behavior is defined by the queue, and components either use the queue as is, or use a different queue.
Having both of these approaches will complicate queue usage a great deal. We want to make it easier for users to use queue's.
Is there a way we could deprecate this behavior so that in a future release we can remove it? One of the reasons for the new queue system was to simplify component usage of the queue's.
Or perhaps elements that do this still use the older queue system? I not really like that idea because it is still complicated.
eventsQueue or eventQueue (like in the document) is just another dilemma - to have a backward compatibility or a right English in the name.
That was a typo on my part and I'll update to eventsQueue
