You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Christian Oldiges (JIRA)" <ji...@apache.org> on 2012/07/20 12:12:34 UTC

[jira] [Created] (WICKET-4665) AjaxChannel.Type.DROP actually allows 2 requests in the "total queue"

Christian Oldiges created WICKET-4665:
-----------------------------------------

             Summary: AjaxChannel.Type.DROP actually allows 2 requests in the "total queue"
                 Key: WICKET-4665
                 URL: https://issues.apache.org/jira/browse/WICKET-4665
             Project: Wicket
          Issue Type: Bug
          Components: wicket
    Affects Versions: 6.0.0-beta3
            Reporter: Christian Oldiges


The schedule JavaScript function of the ajax channel uses a BUSY flag and a request queue in a callbacks array.

If the channel is marked as busy because there is a request currently being executed, the second part of the function is executed and for channel type DROP, the newly scheduled request is put into the callbacks queue.

Using this approach, the dropping channel type actually allows 2 requests in the "total queue".
The one that triggers the busy = true which is still running and the one that is stored into the callbacks array.

Reading the documentation of AjaxChannel.DROP says:

dropping - only the last Ajax request is processed, the others are discarded

		schedule: function (callback) {
			if (this.busy === false) {
				this.busy = true;
				try {
					return callback();
				} catch (exception) {
					this.busy = false;
					Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
				}
			} else {
				Wicket.Log.info("Channel busy - postponing...");
				if (this.type === 's') { // stack
					this.callbacks.push(callback);
				}
				else { /* drop */
					this.callbacks = [];
					//  THIS IS WRONG   this.callbacks[0] = callback;
				}
				return null;
			}
		},

To make it work, the dropping channel should NOT store the currently scheduled request, but simply clear the callbacks array.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Resolved] (WICKET-4665) Add a new AjaxChannel that discards any Ajax requests if there is a running request in the same channel

Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-4665.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.5.8
                   6.0.0
    
> Add a new AjaxChannel that discards any Ajax requests if there is a running request in the same channel
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-4665
>                 URL: https://issues.apache.org/jira/browse/WICKET-4665
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.0.0-beta3
>            Reporter: Christian Oldiges
>            Assignee: Martin Grigorov
>             Fix For: 6.0.0, 1.5.8
>
>
> The schedule JavaScript function of the ajax channel uses a BUSY flag and a request queue in a callbacks array.
> If the channel is marked as busy because there is a request currently being executed, the second part of the function is executed and for channel type DROP, the newly scheduled request is put into the callbacks queue.
> Using this approach, the dropping channel type actually allows 2 requests in the "total queue".
> The one that triggers the busy = true which is still running and the one that is stored into the callbacks array.
> Reading the documentation of AjaxChannel.DROP says:
> dropping - only the last Ajax request is processed, the others are discarded
> 		schedule: function (callback) {
> 			if (this.busy === false) {
> 				this.busy = true;
> 				try {
> 					return callback();
> 				} catch (exception) {
> 					this.busy = false;
> 					Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> 				}
> 			} else {
> 				Wicket.Log.info("Channel busy - postponing...");
> 				if (this.type === 's') { // stack
> 					this.callbacks.push(callback);
> 				}
> 				else { /* drop */
> 					this.callbacks = [];
> 					//  THIS IS WRONG   this.callbacks[0] = callback;
> 				}
> 				return null;
> 			}
> 		},
> To make it work, the dropping channel should NOT store the currently scheduled request, but simply clear the callbacks array.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Assigned] (WICKET-4665) AjaxChannel.Type.DROP actually allows 2 requests in the "total queue"

Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov reassigned WICKET-4665:
---------------------------------------

    Assignee: Martin Grigorov
    
> AjaxChannel.Type.DROP actually allows 2 requests in the "total queue"
> ---------------------------------------------------------------------
>
>                 Key: WICKET-4665
>                 URL: https://issues.apache.org/jira/browse/WICKET-4665
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.0.0-beta3
>            Reporter: Christian Oldiges
>            Assignee: Martin Grigorov
>
> The schedule JavaScript function of the ajax channel uses a BUSY flag and a request queue in a callbacks array.
> If the channel is marked as busy because there is a request currently being executed, the second part of the function is executed and for channel type DROP, the newly scheduled request is put into the callbacks queue.
> Using this approach, the dropping channel type actually allows 2 requests in the "total queue".
> The one that triggers the busy = true which is still running and the one that is stored into the callbacks array.
> Reading the documentation of AjaxChannel.DROP says:
> dropping - only the last Ajax request is processed, the others are discarded
> 		schedule: function (callback) {
> 			if (this.busy === false) {
> 				this.busy = true;
> 				try {
> 					return callback();
> 				} catch (exception) {
> 					this.busy = false;
> 					Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> 				}
> 			} else {
> 				Wicket.Log.info("Channel busy - postponing...");
> 				if (this.type === 's') { // stack
> 					this.callbacks.push(callback);
> 				}
> 				else { /* drop */
> 					this.callbacks = [];
> 					//  THIS IS WRONG   this.callbacks[0] = callback;
> 				}
> 				return null;
> 			}
> 		},
> To make it work, the dropping channel should NOT store the currently scheduled request, but simply clear the callbacks array.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (WICKET-4665) AjaxChannel.Type.DROP actually allows 2 requests in the "total queue"

Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420308#comment-13420308 ] 

Martin Grigorov commented on WICKET-4665:
-----------------------------------------

I think Matej have implemented this functionality and I didn't have the chance someone to explain it to me. So this is how I understood it by reading its JSDoc and follow the logic in the code: 
the already fired request doesn't count, only the requests in the queue count. That is, the already fired request should not be stopped (this will lead to "the client aborted the connection" exceptions), the "busy" flag is there to prevent more than one Ajax requests on the same channel to be fired in the same time. 
DROP and QUEUE affect only the queue of waiting requests.

If DROP was supposed to drop all requests but the one that is currently being executed then the JSDoc would say that it allows only the *first* request, not the *last*.

We may add a third value for AjaxChannel.Type for this new behavior though.
                
> AjaxChannel.Type.DROP actually allows 2 requests in the "total queue"
> ---------------------------------------------------------------------
>
>                 Key: WICKET-4665
>                 URL: https://issues.apache.org/jira/browse/WICKET-4665
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.0.0-beta3
>            Reporter: Christian Oldiges
>
> The schedule JavaScript function of the ajax channel uses a BUSY flag and a request queue in a callbacks array.
> If the channel is marked as busy because there is a request currently being executed, the second part of the function is executed and for channel type DROP, the newly scheduled request is put into the callbacks queue.
> Using this approach, the dropping channel type actually allows 2 requests in the "total queue".
> The one that triggers the busy = true which is still running and the one that is stored into the callbacks array.
> Reading the documentation of AjaxChannel.DROP says:
> dropping - only the last Ajax request is processed, the others are discarded
> 		schedule: function (callback) {
> 			if (this.busy === false) {
> 				this.busy = true;
> 				try {
> 					return callback();
> 				} catch (exception) {
> 					this.busy = false;
> 					Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> 				}
> 			} else {
> 				Wicket.Log.info("Channel busy - postponing...");
> 				if (this.type === 's') { // stack
> 					this.callbacks.push(callback);
> 				}
> 				else { /* drop */
> 					this.callbacks = [];
> 					//  THIS IS WRONG   this.callbacks[0] = callback;
> 				}
> 				return null;
> 			}
> 		},
> To make it work, the dropping channel should NOT store the currently scheduled request, but simply clear the callbacks array.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (WICKET-4665) Add a new AjaxChannel that discards any Ajax requests if there is a running request in the same channel

Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov updated WICKET-4665:
------------------------------------

    Summary: Add a new AjaxChannel that discards any Ajax requests if there is a running request in the same channel  (was: AjaxChannel.Type.DROP actually allows 2 requests in the "total queue")
    
> Add a new AjaxChannel that discards any Ajax requests if there is a running request in the same channel
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-4665
>                 URL: https://issues.apache.org/jira/browse/WICKET-4665
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.0.0-beta3
>            Reporter: Christian Oldiges
>            Assignee: Martin Grigorov
>
> The schedule JavaScript function of the ajax channel uses a BUSY flag and a request queue in a callbacks array.
> If the channel is marked as busy because there is a request currently being executed, the second part of the function is executed and for channel type DROP, the newly scheduled request is put into the callbacks queue.
> Using this approach, the dropping channel type actually allows 2 requests in the "total queue".
> The one that triggers the busy = true which is still running and the one that is stored into the callbacks array.
> Reading the documentation of AjaxChannel.DROP says:
> dropping - only the last Ajax request is processed, the others are discarded
> 		schedule: function (callback) {
> 			if (this.busy === false) {
> 				this.busy = true;
> 				try {
> 					return callback();
> 				} catch (exception) {
> 					this.busy = false;
> 					Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> 				}
> 			} else {
> 				Wicket.Log.info("Channel busy - postponing...");
> 				if (this.type === 's') { // stack
> 					this.callbacks.push(callback);
> 				}
> 				else { /* drop */
> 					this.callbacks = [];
> 					//  THIS IS WRONG   this.callbacks[0] = callback;
> 				}
> 				return null;
> 			}
> 		},
> To make it work, the dropping channel should NOT store the currently scheduled request, but simply clear the callbacks array.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (WICKET-4665) AjaxChannel.Type.DROP actually allows 2 requests in the "total queue"

Posted by "Sven Meier (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419201#comment-13419201 ] 

Sven Meier commented on WICKET-4665:
------------------------------------

I don't know why this implementation keeps one additional callback in the queue, but it has been this way in 1.5.x too (didn't check 1.4.x).

IMHO it would make sense to let the channel drop *all* successive callbacks while busy, as you suggested. But I would like to hear the opinion other developers.

@Igor, @Martin ? 
                
> AjaxChannel.Type.DROP actually allows 2 requests in the "total queue"
> ---------------------------------------------------------------------
>
>                 Key: WICKET-4665
>                 URL: https://issues.apache.org/jira/browse/WICKET-4665
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.0.0-beta3
>            Reporter: Christian Oldiges
>
> The schedule JavaScript function of the ajax channel uses a BUSY flag and a request queue in a callbacks array.
> If the channel is marked as busy because there is a request currently being executed, the second part of the function is executed and for channel type DROP, the newly scheduled request is put into the callbacks queue.
> Using this approach, the dropping channel type actually allows 2 requests in the "total queue".
> The one that triggers the busy = true which is still running and the one that is stored into the callbacks array.
> Reading the documentation of AjaxChannel.DROP says:
> dropping - only the last Ajax request is processed, the others are discarded
> 		schedule: function (callback) {
> 			if (this.busy === false) {
> 				this.busy = true;
> 				try {
> 					return callback();
> 				} catch (exception) {
> 					this.busy = false;
> 					Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> 				}
> 			} else {
> 				Wicket.Log.info("Channel busy - postponing...");
> 				if (this.type === 's') { // stack
> 					this.callbacks.push(callback);
> 				}
> 				else { /* drop */
> 					this.callbacks = [];
> 					//  THIS IS WRONG   this.callbacks[0] = callback;
> 				}
> 				return null;
> 			}
> 		},
> To make it work, the dropping channel should NOT store the currently scheduled request, but simply clear the callbacks array.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira