using BatchBuilder for deploying services on startup

[aloubyansky]

This is what we currently do, i.e. deployments listed in standalone/domain xml are added to BatchBuilder. BatchBuilder is supposed to treat services added to the batch as one deployment, i.e., as I understand, deploy all of them or none if at least one of the services failed.

We touched upon a question (in another thread) whether the server should fail to start if one of its deployments failed. It was decided that the error should be logged but the server continue deploying other services. In this case, we shouldn't use BatchBuilder during server start-up the way we do now.

Or perhaps the concept of BatchBuilder should be advanced and a few different implementations should be provided, e.g.

- if any of the deployments fail then fail the whole batch;

- if some specific of the deployments fail then fail the whole batch;

- each deployment isolated and has no affect on others (kind of a fake batch or no batch).

[dmlloyd]

Alexey Loubyansky wrote:

This is what we currently do, i.e. deployments listed in standalone/domain xml are added to BatchBuilder. BatchBuilder is supposed to treat services added to the batch as one deployment, i.e., as I understand, deploy all of them or none if at least one of the services failed.

We touched upon a question (in another thread) whether the server should fail to start if one of its deployments failed. It was decided that the error should be logged but the server continue deploying other services. In this case, we shouldn't use BatchBuilder during server start-up the way we do now.

Or perhaps the concept of BatchBuilder should be advanced and a few different implementations should be provided, e.g.

- if any of the deployments fail then fail the whole batch;

- if some specific of the deployments fail then fail the whole batch;

- each deployment isolated and has no affect on others (kind of a fake batch or no batch).

I don't think that special implementations of BatchBuilder are the solution here.  We do need to make a change to MSC so that batch errors are handled differently.  We need to put the decision to cancel the batch into the hands of the caller by way of (for example) a failure list.  Not using batches during startup is a non-option however: without using a batch, interdependencies in deployment units cannot be correctly resolved.

Again the type of failure is significant here: a duplicate service name or illegal circular dependency is more "fatal" to a batch.  A batch which contains a service which can't start is basically harmless to the running state of the system and the ability to process additional deployments.