Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multi-thread option to run multiple requests at a time #18

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

sbutlerjr
Copy link
Contributor

Execute multiple HTTP requests for speed, wait for result and return back array of results.

Execute multiple HTTP requests for speed, wait for result and return back array of results.
@jcompagner
Copy link
Contributor

but we already have executeAsync() on all the request you can fire already multiply at once

So why do you really need this specific method, to kind of join them in one go ?

@sbutlerjr
Copy link
Contributor Author

sbutlerjr commented Nov 21, 2024

Because you can't wait/pause until they all come back to join them all together with the rest_ws plugin when building an API. This is important when being used in building a RESTful API in Servoy that also needs to consume other API's. I attempted to use executeAsync with continuations, which kind of partially worked in a normal Servoy client but failed in a headless client. It was also very very clunky implementation with continuations.

My use case is building an API in Servoy to return back shipping rates. It uses product dimensions in the app and then consumes multiple API's for DHL, FedEx, and UPS, then merges the results back into a unified response and returns the result.

If I use executeAsync(), there is no way to wait for the responses to return the unified result back to the Servoy API response. So the only option is to execute them one-by-one, which is slow. Its so slow that it doesn't return back the responses quickly enough for ecommerce integrations like Shopify, so it times out and the user doesn't see available shipping options in their shopping cart for checkout.

I have this working in a separate plugin to meet my own needs, but thought it would be useful to include in the standard plugin for others with similar use cases.

@sbutlerjr
Copy link
Contributor Author

sbutlerjr commented Nov 21, 2024

The other option to accomplish something similar with a Servoy API while being able to utilize executeAsync would be to add something to the rest_ws plugin so I could do something like

return plugins.rest_ws.wait(callbackFunction, timeToWait)

Then I could have the Servoy API request keep waiting until all my consumed async callbacks have completed, and then finally return the result back to the Servoy API response. So the Servoy API would return the result back from the callbackFunction, which could keep checking if the async callbacks from the consumed API's have completed, merge them together and return the unified response to the Servoy API response.

Forgot the Runner class
@jcompagner
Copy link
Contributor

jcompagner commented Nov 22, 2024

ah you want to kind of "async" do a number of request (at the same time) but wait for the output of all of them
You can already do this by using async and then having a callback that sets a thing and then a but ugly application.sleep(500) (or updateUI) and test after every sleep...

The problem is with your current code is that you start up a thread executor inside this and then use the base request that will use a AsyncHttpClient that executes stuff async but waits for the results an gives that then back to your thread that waits again.
(your thread doesn't really do anything except kicking of another internal thread)

I think the impl should really be that BaseRequest exposes a internal execute method that returns this future:
https://github.com/Servoy/servoy-extensions/blob/master/com.servoy.extensions/src/com/servoy/extensions/plugins/http/BaseRequest.java#L250

so lines 202->305 should be in a package scope method that returns that future and then the new method on HttpClient that executes them all at once will call that method and waits for all the futures that are coming back..

this way its a lot less new code and not a new ThreadPool usage which in the end doesn't do much

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants