I am implementing a web client for my app and one of the methods from the Server is the one that generates reports and returns the result (usually on PDF).
Some of the reports are going to be generated fast, but some other will probably take on the real world up to several minutes, maybe dozens, so I face the problem of the response taking more than the Timeout for the connection.
I thought that just moving to the _Async version of the methods would avoid the timeout generated by the transport but apparently that’s not the case (or maybe I did something wrong). I searched here for info and found some posts pointing to the chat examples, which, for what I can see, use another technology, event sinks, which I haven’t used before, and I am not sure in a very uncontrolled settings (a web app) would be a good way.
So, before investing time there, I wonder if that’s the “correct” way to solve this kinds of needs? It was mentioned also to just change the timeout (or disable it) before the call to the long-running methods, which seems like a easy way to “solve” this, but I’m not sure if it’s better.
For reference: the server is on C++Builder, and the client is on .NET.
Async really just affects client code semantics (whether the execution flow of the thread you can from blocks and waits, or whether you get an async response later. Under the hood, it still does a HTTP request and waits for a response (just asynchronously).
What you want, I think is to create an API that can queue off a task to be done on the server, and be done with that request. And then later get a response form the server when the result is ready (the server could send the result, in that callback, or you could make a second request to collect it).
EventSinks are a good solution for this. It will require a bit more administrative overhead on your end, but in the long run, will give yu a better API and UX for long0-running server tasks.
May not apply to you, but I am building a WASM client that generates reports for the user & all done in my client Ap with the report in HTML which the user can see on-line & if he desires he can turn it in to a Word or PDF document. I don’t use the server, but without knowing what you are doing, I would consider that if the Server is required rather than roll your own, I might have the Server return the data to me to to build my own HTML report (cuz that is easy for the reports I make). --tex
Thanks for the suggestion. Unfortunately we have 20+ years of reports implemented already, and moving the code to the client would imply implementing the same report in the different clients we intend to support. And using different report engines… not an option for us.
Also, some (most) of the time spent on the reports is actually on running queries against the database, so the timeout might still occur even when doing “all” on the client.
We are going to go with the async and the event sinks, as suggested by RemObjects, it just needs some reengineering to be able to handle this, which I am still not 100% sure how to do in our current code/architecture.
Please let me know how everything works out when you’re satisfied cuz I could have the problem in the future, esp searching large DB’s. Good luck. --tex