-
30. Re: a4j:queue. The next round.
sergeysmirnov Nov 4, 2008 12:57 PM (in response to sergeysmirnov)Jay, this is the example:
.... <a4j:queue name="foo" requestDelay="0" ..... /> .... <h:inputText> <a4j:support event="onkeyup" eventsQueue="foo" requestDelay="500" ..... /> </h:inputText> ..... <a4j:poll interval="200" eventsQueue="foo" /> ....
So, developer wants:
1. to use the same queue for both support and poll to avoid processing two requests simultaneously.
2. to reduce the number of unnecessary requests from the user input when she typing
3. to send a poll request without the additional delay (No reason to wait extra 500ms when poll request comes to the queue)
It is possible if the local attribute (like on the a4j:support above) can override the attribute on the queue. This is our proposal.
If not, developers has no chance to meet all three needs.
* Defining two queues eliminates #1
* Having requestDelay="0" eliminates #2
* Having requestDelay="500" eliminates #3
P.S. I suggest, in order to avoid latency by default, requestDelay="0" should be a default value for a4j:queue. There is just a few cases when an extra delay is very helpful. -
31. Re: a4j:queue. The next round.
sergeysmirnov Nov 4, 2008 2:21 PM (in response to sergeysmirnov)One more issue:
If you reference a named queue that does not exist a new named queue will be created with all default settings.
OPEN ISSUE: Should this raise a warning?
In the previous implementation of RichFaces, queue is always created implicitly. So, if we add some sort of client side warning (alert box or so on), it means that developers have to edit application just after upgrade. Otherwise, it will be very unpleasant behavior for the end users.
At the same time, the disadvantage of the silence approach might be the problem to figure our the source of unexpected behaviour if developer has a typo in the name.
I suggest to add [INFO] or [WARNING] level of message to the server log, so developer can check the issue working in the developer's mode. -
32. Re: a4j:queue. The next round.
jbalunas Nov 4, 2008 2:42 PM (in response to sergeysmirnov)"SergeySmirnov" wrote:
One more issue:
I suggest to add [INFO] or [WARNING] level of message to the server log, so developer can check the issue working in the developer's mode.
I agree - this is the type of message/warning I was thinking of. -
33. Re: a4j:queue. The next round.
jbalunas Nov 4, 2008 2:50 PM (in response to sergeysmirnov)"SergeySmirnov" wrote:
Jay, this is the example:
So, developer wants:
1. to use the same queue for both support and poll to avoid processing two requests simultaneously.
2. to reduce the number of unnecessary requests from the user input when she typing
3. to send a poll request without the additional delay (No reason to wait extra 500ms when poll request comes to the queue)
It is possible if the local attribute (like on the a4j:support above) can override the attribute on the queue. This is our proposal.
If not, developers has no chance to meet all three needs.
* Defining two queues eliminates #1
* Having requestDelay="0" eliminates #2
* Having requestDelay="500" eliminates #3
ok - this makes sense to me :-) I can see the reasons for this behavior. There will be times when a 2+ components will generate a lot of traffic and should be queued. However if they require different settings and use different queues, then they can still overwhelm the server. With this approach they can use the same queue and still have their own settings.
Obviously only some of the properties can be overwritten and they should be defined. In other other words individual components should not be able to adjust the queue size, or sizeExceededBehavior. Anything that is queue specific should not be available for override.
Ilya - can you update the wiki with this information?
P.S. I suggest, in order to avoid latency by default, requestDelay="0" should be a default value for a4j:queue. There is just a few cases when an extra delay is very helpful.
+1 -
34. Re: a4j:queue. The next round.
ilya_shaikovsky Nov 25, 2008 9:42 AM (in response to sergeysmirnov)RichFaces 3.3.0.BETA1 has been deployed to: http://repository.jboss.org/maven2/org/richfaces/ui/richfaces-ui/3.3.0.BETA1/
So, global queue mechanism including a4j:queue component available for public review within this BETA. -
35. Re: a4j:queue. The next round.
ronanker Dec 5, 2008 5:24 AM (in response to sergeysmirnov)concerning "sizeExceededBehavior" and other usefull improvements in queues (for future)
it would be cool to have more javascript hooks :
onQueueFull
onQueueNoLongerFull
onQueueUsed
onQueueEmpty
we could use it like this :
onQueueUsed -> show an image in the corner that indicates work
onQueueEmpty -> hides the corner image
onQueueFull -> show a 100% blocking transparent DIV in order the user can't click anywhere, so that he won't be able to throw sizeExceededBehavior
onQueueNoLongerFull -> remove the blocking DIV
the other way of doing something like it usind a4j:status is to have a global counter and increment it onStartOfAjaxRequest and decrement it onEndOfAjaxRequest
and take action on the counter value, but it won't be able to protect the queue as onStartOfAjaxRequest isn't called at the time request is put in the queue but at the time it's fired.
maybe we can have these hooks:
onNewRequestInQueue
onRequestFired -
36. Re: a4j:queue. The next round.
ronanker Dec 5, 2008 5:29 AM (in response to sergeysmirnov)when i say "blocking transparent DIV" it can be a grey semi-transparent DIV with an image in the center indicating overload working...
this is let to the developper of the application. -
37. Re: a4j:queue. The next round.
nbelaevski Dec 7, 2008 1:42 PM (in response to sergeysmirnov)So we have to add to queue:
1. status attribute
2. queue/dequeue events and getSize()/getMaximumSize() methods
Having all this stuff will allow to show modal panel blocking user interactions and preventing oversize. -
38. Re: a4j:queue. The next round.
ilya_shaikovsky Dec 8, 2008 9:38 AM (in response to sergeysmirnov)So guys.. let we add next additional attributes:
status - our stadard attribute. Defined on the queue - it points all the ajax components which uses the queue to some status component by its id.
Event attributes
onrequestqueued - should be fired after the request added to the queue
And already introduced attrubute oncomplete coulod be used to handle each queue request completion
JS API function mentioned by Nick seems also ok for me in order to check if the queue are full/no more full in onrequestadded, onsubmit or oncomplete -
39. Re: a4j:queue. The next round.
ilya_shaikovsky Dec 8, 2008 9:46 AM (in response to sergeysmirnov)onrequestqueued - should be onrequestqueue
-
40. Re: a4j:queue. The next round.
jbalunas Dec 8, 2008 9:55 AM (in response to sergeysmirnov)I really like the new callbacks and attributes - good ideas!!
-Jay -
41. Re: a4j:queue. The next round.
nbelaevski Dec 8, 2008 10:46 AM (in response to sergeysmirnov)We definitely need onrequestdequeue event also, oncomplete is not enough for all cases. I'll add it too.
-
42. Re: a4j:queue. The next round.
nbelaevski Dec 8, 2008 12:37 PM (in response to sergeysmirnov)https://jira.jboss.org/jira/browse/RF-5244 - issue for the latest RFCs
-
43. Re: a4j:queue. The next round.
nbelaevski Dec 16, 2008 12:18 PM (in response to sergeysmirnov)We also need a way to notify components that request has been dropped (e.g. to resolve this issue: https://jira.jboss.org/jira/browse/RF-5375), so I'm adding onqueuerequestdrop internal event to control this situation.
Component scripts that wish to be notified of the case should use the following:if (!options.onqueuerequestdrop) { options.onqueuerequestdrop = function(query, options, event) { //requeue component again }; } A4J.AJAX.Submit(containerId,form,null,options);
'this' inside event handler points to queue object -
44. Re: a4j:queue. The next round.
nbelaevski Sep 10, 2009 2:29 PM (in response to sergeysmirnov)RFC for "View Changes and requests waiting in queue" section has been posted here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160964