Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2018-01

CGI/FastCGI and WS request with a max time response

5 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marcos Douglas B. Santos

Hi,

I have a FastCGI application which needs to receive an user request but, in some cases, the app should consume a WebService(WS) before make the response to the user.
The problem is that the WS could take so long time that the entire request will broke with a "time out".

My question is: Can I consume this WS with a max time to wait? Would be better doing this in the code instead of change parameters in the webserver. But, if there is no (simple) way to do that in the code, the webserver more used to this app is Microsoft IIS.

Best regards,
Marcos Douglas

Reply by email

Michael Van Canneyt
to Marcos Douglas B. Santos
Marcos Douglas B. Santos wrote 9 lines
Hi, I have a FastCGI application which needs to receive an user request but, in some cases, the app should consume a WebService(WS) before make the response to the user. The problem is that the WS could take so long time that the entire request will broke with a "time out". My question is: Can I consume this WS with a max time to wait?

If you use a thread to consume it, yes.

Without more info on how you consume this webservice, it's difficult to answer this.

Michael.

Reply by email

leledumbo
to Marcos Douglas B. Santos: I have a FastCGI application which needs to receive an user request but, in some cases,…
The problem is that the WS could take so long time that the entire request

will broke with a "time out".

I suggest making the request handling asynchronous instead. So request will only register and return some unique id to the requester, then do call to the WS in background thread. An endpoint shall be provided that when given a unique id will check whether the corresponding thread has finished executing or not, returning 200 + response data when done, and 202 if still in progress. This endpoint shall be called in regular interval by the requester, until it finishes processing or your server dies (500).

Reply by email

Marcos Douglas B. Santos
to Michael Van Canneyt: If you use a thread to consume it, yes. Without more info on how you consume this…
Michael Van Canneyt wrote 5 lines
If you use a thread to consume it, yes. Without more info on how you consume this webservice, it's difficult to answer this.

Yes, sorry. I should explained more.
I'm using WST -> http://svn.code.sf.net/p/lazarus-ccr/svn/wst (rev.
5836) to consume WS.
Until now, I didn't find how to set a timeout in WST objects — is this possible? As you already said, I thought to use a thread, but I may need to control this manually... ideas how to do this as simple as possible?

My requirement is: If WS do not respond in "X seconds", forget it and return the "code Y".

Regards,
Marcos Douglas

Reply by email

Marcos Douglas B. Santos
to leledumbo: will broke with a "time out". I suggest making the request handling asynchronous instead.…
leledumbo wrote 10 lines
> The problem is that the WS could take so long time that the entire request will broke with a "time out". I suggest making the request handling asynchronous instead. So request will only register and return some unique id to the requester, then do call to the WS in background thread. An endpoint shall be provided that when given a unique id will check whether the corresponding thread has finished executing or not, returning 200 + response data when done, and 202 if still in progress. This endpoint shall be called in regular interval by the requester, until it finishes processing or your server dies (500).

Interesting, but I can't do this way.
It should be just one call from client (desktop app and website) to my REST service.
My service encapsulates the WS.
As I wrote previously to Michael, if the WS do not respond in "X seconds", my service should forget it and return a "code Y".

Best,
Marcos Douglas

Reply by email