Start a new topic

Concurrent request queuing

We noticed that when there are multiple requests issued from the same client, the requests seem get queued up, the last one taking several seconds to respond. In some cases, if the queued up requests were of the same type as the last one, we want to be able to drop all those previous requests.



Is there a way to cancel requests? What is the max number of simultaneous requests allowed per user?

Thanks @Edward‌! Good suggestion on using the blocking with my own executor, I overlooked that. :\
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();





@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?
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 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.
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?
Login or Signup to post a comment