You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because of thread locks, right now the REST API follows this flow when handling service calls from server to endpoint:
ServiceRequest received at REST API replica of endpoint
REST API sends POST to callback URL of endpoint
Endpoint send HTTP OK
REST API waits for POST with ServiceResponse
Endpoint sends POST to REST API with ServiceResponse
REST API relays the ServiceResponse to the original caller
The thing is that 3 must strictly happen before 4, because REST API will block until 3 before proceeding with 4. This means that endpoint clients must be careful not send the ServiceResponse before the HTTP OK is first delivered. Otherwise, the ServiceResponse may not be processed until the REST API timeout ellapses (30 seconds by default).
Those steps should be best practice, but anyway, it would be a good idea to rewrite a bit the way the REST API deals with thread locks to avoid the 30 second delay even if worse case scenarios.
Another enhancement for this would be allowing endpoints to respond "synchronously", by sending the serialized ServiceResponse within the HTTP OK, and then REST API does not need to wait.
The text was updated successfully, but these errors were encountered:
Because of thread locks, right now the REST API follows this flow when handling service calls from server to endpoint:
The thing is that 3 must strictly happen before 4, because REST API will block until 3 before proceeding with 4. This means that endpoint clients must be careful not send the ServiceResponse before the HTTP OK is first delivered. Otherwise, the ServiceResponse may not be processed until the REST API timeout ellapses (30 seconds by default).
Those steps should be best practice, but anyway, it would be a good idea to rewrite a bit the way the REST API deals with thread locks to avoid the 30 second delay even if worse case scenarios.
Another enhancement for this would be allowing endpoints to respond "synchronously", by sending the serialized ServiceResponse within the HTTP OK, and then REST API does not need to wait.
The text was updated successfully, but these errors were encountered: