Redirect Notice
As of April 12th, you must go to Progress SupportLink to create new support cases or to access existing cases. Please, bookmark the SupportLink URL and use the new portal to contact the support team.
How can we help you today?
Concurrent request queuing
6 CommentsSorted by Oldest First
Currently the android library will execute all requests serially, and we are using the SerialExecutor implementation described here: http://developer.android.com/reference/java/util/concurrent/Executor.html
We made this decision to ensure good performance on older devices, to prevent any memory and/or performance issues from managing multiple threads.
As for cancelling requests, that is in the backlog, but if you don't mind, could I get your opinion on it? My main concern is that if a request is cancelled after it has been sent over the network, the cancellation won't actually do anything. While it is true that if there are multiple requests queued, then a cancel could prevent one from executing, but it it pretty much required that the request be cancelled before it is executed which is almost impossible to guarantee. As such, I'm hesitant to release a cancel feature that "may or may not work, depending on how quickly you can call cancel". What would you like to see for a cancelled request?
We made this decision to ensure good performance on older devices, to prevent any memory and/or performance issues from managing multiple threads.
As for cancelling requests, that is in the backlog, but if you don't mind, could I get your opinion on it? My main concern is that if a request is cancelled after it has been sent over the network, the cancellation won't actually do anything. While it is true that if there are multiple requests queued, then a cancel could prevent one from executing, but it it pretty much required that the request be cancelled before it is executed which is almost impossible to guarantee. As such, I'm hesitant to release a cancel feature that "may or may not work, depending on how quickly you can call cancel". What would you like to see for a cancelled request?
@Edward Fleming
Once the HTTP request is out, it is not possible to cancel it, and that is understandable. However, there are benefits to cancel all the same:
- If the request is not out yet, avoid an extra HTTP request. This is a big win if you have things on queue.
- If the request is out, but we no longer care for the reply:
- Avoid waiting until the next request begins.
- Avoid unwanted calls to listeners/handlers.
That last point is of particular interest, since the client doesn't return a request object, nor provides a way to attach a context or identifier to a request, keeping track of the current request is troublesome. If the success listener starts setting up views but the response comes after the Activity is torn down, that's an exception for sure. It would be much nicer if I can just cancel unwanted requests and not worry about dealing with mysterious callbacks 10 seconds later.
Once the HTTP request is out, it is not possible to cancel it, and that is understandable. However, there are benefits to cancel all the same:
- If the request is not out yet, avoid an extra HTTP request. This is a big win if you have things on queue.
- If the request is out, but we no longer care for the reply:
- Avoid waiting until the next request begins.
- Avoid unwanted calls to listeners/handlers.
That last point is of particular interest, since the client doesn't return a request object, nor provides a way to attach a context or identifier to a request, keeping track of the current request is troublesome. If the success listener starts setting up views but the response comes after the Activity is torn down, that's an exception for sure. It would be much nicer if I can just cancel unwanted requests and not worry about dealing with mysterious callbacks 10 seconds later.
Sorry for the delay in getting back to you-- I've been convinced, and have added cancelling requests to the backlog for the android library. Keep an eye out for this in a future release!
@Edward sorry for digging up this old thread, but I was wondering if there was a chance to add an option to use a THREAD_POOL_EXECUTOR for requests. Our application uses AppData extensively and leverages collection aggregation calls to populate associated data, which would benefit immensely from requests being executed on multiple-threads.
On another note, for canceling requests OkHttp could be used to terminate a currently running request. Example at https://github.com/square/okhttp/wiki/Recipes
Keep up the good work! :smile:
> @Edward said:
> Currently the android library will execute all requests serially, and we are using the SerialExecutor implementation described here: http://developer.android.com/reference/java/util/concurrent/Executor.html
>
> We made this decision to ensure good performance on older devices, to prevent any memory and/or performance issues from managing multiple threads.
>
> As for cancelling requests, that is in the backlog, but if you don't mind, could I get your opinion on it? My main concern is that if a request is cancelled after it has been sent over the network, the cancellation won't actually do anything. While it is true that if there are multiple requests queued, then a cancel could prevent one from executing, but it it pretty much required that the request be cancelled before it is executed which is almost impossible to guarantee. As such, I'm hesitant to release a cancel feature that "may or may not work, depending on how quickly you can call cancel". What would you like to see for a cancelled request?
On another note, for canceling requests OkHttp could be used to terminate a currently running request. Example at https://github.com/square/okhttp/wiki/Recipes
Keep up the good work! :smile:
> @Edward said:
> Currently the android library will execute all requests serially, and we are using the SerialExecutor implementation described here: http://developer.android.com/reference/java/util/concurrent/Executor.html
>
> We made this decision to ensure good performance on older devices, to prevent any memory and/or performance issues from managing multiple threads.
>
> As for cancelling requests, that is in the backlog, but if you don't mind, could I get your opinion on it? My main concern is that if a request is cancelled after it has been sent over the network, the cancellation won't actually do anything. While it is true that if there are multiple requests queued, then a cancel could prevent one from executing, but it it pretty much required that the request be cancelled before it is executed which is almost impossible to guarantee. As such, I'm hesitant to release a cancel feature that "may or may not work, depending on how quickly you can call cancel". What would you like to see for a cancelled request?
Hey,
Currently the executor isn't exposed-- however I am planning on shipping an update to the library sometime next week and can do my best to include public methods to expose this.
As a workaround, you can wrap the Blocking API methods in your own Async Tasks, and call the executeOnExecutor method: http://developer.android.com/reference/android/os/AsyncTask.html#executeOnExecutor(java.util.concurrent.Executor, Params...)
Note the Blocking API is accessible the same as the Async ones-- just append `Blocking` to the end of the method, and call `execute()` in your `doInBackground(...)` method. For example, to get from appdata by Id with the Blocking apis:
MyEntity entity = myClient.AppData("myCollection",MyEntity.class).getBlocking(myEntityId).execute();
Currently the executor isn't exposed-- however I am planning on shipping an update to the library sometime next week and can do my best to include public methods to expose this.
As a workaround, you can wrap the Blocking API methods in your own Async Tasks, and call the executeOnExecutor method: http://developer.android.com/reference/android/os/AsyncTask.html#executeOnExecutor(java.util.concurrent.Executor, Params...)
Note the Blocking API is accessible the same as the Async ones-- just append `Blocking` to the end of the method, and call `execute()` in your `doInBackground(...)` method. For example, to get from appdata by Id with the Blocking apis:
MyEntity entity = myClient.AppData("myCollection",MyEntity.class).getBlocking(myEntityId).execute();
Thanks @Edward! Good suggestion on using the blocking with my own executor, I overlooked that. :\
Street Beat
Is there a way to cancel requests? What is the max number of simultaneous requests allowed per user?