I believe the current timeout is one second.
So we aren’t talking anything like microseconds 8)
It’s also configurable, though configuration is up to the administrator of the SGS instance your running on.
Really, the time out is there just to keep errant tasks from permenently blocking up resources. If you have logging enabled you should see a clear warning if a task is canceled due to timeout.
In terms of designing managers… hmm… without rewriting the whole manual lets see what I can say…
Managers ae really split into two pieces: a manager and a service. A manager is the interface that app sees. Services have access to the rest of the environment. A manager without a service behind it can’t really do anything that the app code can’t, its just a way of binding code to the environment rather then the app, so what your likely talking about is a service.
Services can have their own worker threads and do blocking Io though they should do that Io on their own thread and not on a task’s thread of control. They are pretty straight forward Java code until you get into the areas of transactions and persistence.
A service can participate in a transaction, and may have to in order to do its job correctly. As an example, the Channel service doesn’t actually send any data until the task’s associated transaction commits,
A service may also need to store information in order to properly finish its operation after a system failure. As an example, the channel service uses the data service to persist information about channels.
When a service needs to inform the app of the results of an operation, it does so by queuing a new task using the task service.
Thats a very rough and high level over-view.
