Hi Stefan,
I observed that when a runtime configuration with a app already present (downloaded and unpacked) accessing a service on new server (version) is deployed, the app gets a Service_denied exception while the new server (version) is being downloaded, verified or unpacked.
Wouldn't it be better to start all components in the runtime configuration only when all possible downloading is complete?
the sculpt manager is already supposed to work that way. A subsystem is started only if all children referred to the subsystem's routing rules are present in the runtime (by looking at the children's names in the report/runtime/state report). Otherwise, the sculpt manager displays messages like "<subsystem> requires <server-name>" in the "Runtime" dialog and defers the start of the subsystem.
I guess that you hit a corner case not properly handled so far. Can you confirm that my understanding of the situation is correct? You already had a server running. Now you changed the pkg version but keep the server's name the same. This triggers the download of the new pkg. While downloading, you start a client. Unexpectedly, the client starts before the server's new pkg is ready. It could very well be that such an on-the-fly version update is the problem. To investigate, I would very much appreciate a simple sequence of steps (preferably using the RAM fs) to reproduce the behavior.
Otherwise we either need to make components tolerant to Service_denied exceptions or detect such error conditions and restart the runtime entirely.
We should better address the corner case. ;-)
Cheers Norman