-
Notifications
You must be signed in to change notification settings - Fork 0
Reexamine default timeouts #66
Comments
Increasing this would mean increasing the 5 min buffer in the contracts as well. It's that way because event processing waits for the instance to be deployed, this would have to be decoupled to make them independent which has its own complications. |
Is it not possible to terminate the setup process when a jobClose request is received on contract?
Can you elaborate please? |
Yes, hence the second part.
Event processing happens sequentially, with potential dependencies between events (e.g. enclave deploy vs enclave update vs enclave close). Today, the sequential processing makes it so we don't need to track any of this, can just keep processing events one by one as they come. If you want jobClose to even be handled while enclave deployment is still happening, you would have to process events while deployment is happening which then brings up the question of what happens when you get update or close events. Some form of queue and associated queue management has to be implemented now. Even with this, you probably don't want to deploy the original enclave after you have seen an update event, stuff like this has to be encoded. |
I am assuming everything is globally sequential(not per job sequential). Does this mean 5 min is an optimistic limit and it is possible that enclave shutdown happens after the 5 min window? BTW am I right in understanding that the only limitation for changing the 5 min window to 15 min is changing the contract close job timeout. Anything else? |
The default timeouts of 2 min for downloading the complete enclave image file and 5 min for the enclave setup process might put restrictions on the services that can host enclave image and also the network speeds. Please reexamine the default timeouts to ensure they can support wide range of sources.
The text was updated successfully, but these errors were encountered: