How to set timeout value on config file for erocci server ?

[cgourdin]

No description provided.

[jeanparpaillon]

I suppose you're speaking about timeout on a backend call ?
Actually, there is no specific parameter to setup this.
If processing the request takes too long, I would prefer to adopt more "HTTP-like" behaviour and answering "202 Accepted" (see https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)
From D-Bus API point of view, that could be achieved by raising an exception, for instance: "org.ow2.erocci.backend.Accepted"

[cgourdin]

When i have a long (more than 5 seconds) working thread in erocci-dbus-java, erocci send a 500 internal error. I want to expand the timeout timer of Erocci from 5 to 10secs for exemple. That is my question. I think this should be parameterized in config file for enhanced user experience.
All http server have timeout specifications, so i think erocci has one.
This maybe a new feature.

[jeanparpaillon]

Allowing too long timeout is a really bad practice, for performance and/or security reasons.
Each request consumes CPU and RAM and keeping the connection open for too long can easily lead to DDoS. That's the reason why every HTTP server has default timeout of a few seconds (Apache HTTPD was 15 sec until 2.0 and 5 sec from 2.2 for instance).

If you want to handle long requests, the answer is the HTTP code 202, which can be implemented in erocci as I described above, but not extending timeouts.

Extending the timeout in erocci would be complex because a lot of code (in erocci but also in the HTTP framework) are based on these widely adopted timeout values.

[jeanparpaillon]

My proposal for backend API evolution, compliant with REST architectures / HTTP best practices:

• if you can quickly handle the request, returns out arguments (as described in D-Bus API)
• if requests requires further processing, throws DBus Exception "org.ow2.erocci.backend.Accepted" (and HTTP stack will answer "202 Accepted"
• Further requests on the same url:
  • Get: if the processing is not finished -> throws Accepted, if yes, returns standard out arguments
  • Create / Update: while processing is not finished (resource is not totally created), these calls should throw "org.ow2.erocci.Conflict"

[jeanparpaillon]

Suggestion: if you don't know how much time you need for treating the request, you can even implement the following:

• treat each request in a separate thread, then launch a timer (eg, 2 sec)
• either the thread finishes before the timeout and you can answer,
• either the thread do not end and you answer 202

(thinking loud) As this is a generic solution, I could implement it in the backend manager...