0

When defining a timeout in my CF destination it seems that my timeout property gets completely ignored. The Destination is defined in the destination service-instance and bound to my approuter + srv module.

Destination Properties

When calling my service the request fails always after the (default) 30 Seconds with 504 gateway timeout although I’m giving a timeout of 300 000 ms via the destination properties. I also tried to achieve the same through defining the timeout in the mta.yaml, but as well no success so far...

The destination itself is definitely found and working, when I’m limiting the results the request resolves and I get data displayed.

Any ideas what’s going wrong?

Boghyon Hoffmann
  • 17,103
  • 12
  • 72
  • 170
RNLS0176
  • 115
  • 4
  • 13
  • Can you share with us from which documentation you found that this parameter is supposed to influence something? – Emdee Apr 27 '20 at 06:03
  • https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/ba527058dc4d423a9e0a69ecc67f4593.html#loioba527058dc4d423a9e0a69ecc67f4593__section_bv4_tdf_x1b – RNLS0176 Apr 27 '20 at 10:03

3 Answers3

0

I've never seen support for a destination property "timeout". I wonder what library is reading and acting upon this field. At least not the SAP Cloud SDK.

There are certainly ways to customize the default 30s limit for instances of the Apache HttpClient. But I assume this really doesn't tackle the main problem. What is the reason for a request taking longer than 30s? I would consider this delay hardly acceptable.

Instead I would recommend introducing pagination to your request. My assumption is you can specify some top/skip boundaries. I can give further suggestions, if you provide sample code, e.g. to the failing request.

Alexander Dümont
  • 903
  • 1
  • 5
  • 9
  • I found the timeout property [here](https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/ba527058dc4d423a9e0a69ecc67f4593.html#loioba527058dc4d423a9e0a69ecc67f4593__section_bv4_tdf_x1b). – RNLS0176 Apr 23 '20 at 15:11
  • What I'm trying to achieve is combine a HANA data source with a CRM data source in a CDS view via CAP. So I read all my database entries (currently 74 entries) and hook into this with @AfterQuery to fetch some additional information for this entries from CRM backend which results in 74 additional queries which take longer than 30 seconds ... – RNLS0176 Apr 23 '20 at 15:19
  • 1
    "74 additional queries" as in individual requests to the destination? If yes, then the _SAP Cloud SDK_ cannot really help here, because the timeout is happening either on SCP proxy level (e.g. _approuter_) or on user side (e.g. browser/postman). I assume some of those queries are independent from the actual user request and can be run in advance. You can work with **asynchronous requests and caching** the result for x minutes. Caching data in application memory is cheaper than waiting for 74 queries to complete.per request. – Alexander Dümont Apr 24 '20 at 09:00
0

It's not handled by SDK unfortunately. You can try this:

cf set-env INCOMING_CONNECTION_TIMEOUT 3600000 You can also check this answer: https://answers.sap.com/questions/12937267/cloud-foundry-application-router-http-502-after-2.html

Cloud SDK has nothing to do with it most probably, as timeout comes from some server even behind app router. You can try with POSTMAN or another API tool to see if you have the same problem.

If the payload is too big or server closes the connection because of error you'll have to use pagination with top/skip or find where the request sequence fails and why.

Artyom Kovalyov
  • 374
  • 3
  • 11
  • cf set-env INCOMING_CONNECTION_TIMEOUT 3600000 did not help out, problem persists in postman – RNLS0176 Apr 23 '20 at 15:10
  • If Postman fails SDK wouldn't help either. It's generally not the tool to configure your Cloud Foundry instances. If your CAP service takes too long to return a response you have to either optimize its performance or approach CF support to properly configure all the timeouts in your request pipeline to match the longest response time. – Artyom Kovalyov Apr 24 '20 at 08:20
0

Looks like you need to provide "HTML5.SocketReadTimeoutInSeconds" property in second instead of ms.

Артем Лисовский
  • 1
  • 1