ServiceMix version deployment conflicts
----------------------------------------
Key: SM-1547
URL: https://issues.apache.org/activemq/browse/SM-1547
Project: ServiceMix
Issue Type: Bug
Components: servicemix-core
Affects Versions: 3.2.1
Reporter: Trevor Pounds
Priority: Critical
I have seen a scenario, when upgrading a service assembly (i.e. 1.0.0 to 1.0.1)
between restarts of ServiceMix, where the AutoDeploymentService tries to start
and update the 1.0 sa when it doesn't exist and subsequently undeploys the 1.1
version as well. The following steps can be used to create the problem:
# Start with default ServiceMix installers and test-sa-1.0.0.zip in "hotdeploy"
directory (test-sa-1.0.0.zip is deployed fine)
# Stop ServiceMix
# Remove test-sa-1.0.0.zip from "hotdeploy"
# Add new test-sa-1.0.1.zip to "hotdeploy"
# Start ServiceMix (see below log for bug details)
I see this sequence of events in the log. The log file shows that the
deployment service is confused on how to handle a service assembly with the
same base name and different versions.
{noformat}
... | bi.framework.DeploymentService 690 | Restoring service assemblies
... | ework.ServiceAssemblyLifeCycle 111 | Starting service assembly: test-sa
... | mix.jbi.container.JBIContainer 642 | ServiceMix JBI Container
(localhost) started
... | ramework.AutoDeploymentService 646 | Directory: hotdeploy: Archive
changed: processing test-sa-1.0.0.zip ...
... | ework.ServiceAssemblyLifeCycle 207 | Shutting down service assembly:
test-sa
... | ework.ServiceAssemblyLifeCycle 207 | Shutting down service assembly:
test-sa
... | bi.framework.DeploymentService 683 | UnDeployed ServiceUnit test-jms-su
from Component: servicemix-jms
... | bi.framework.DeploymentService 683 | UnDeployed ServiceUnit
test-quartz-su from Component: servicemix-quartz
... | ework.ServiceAssemblyLifeCycle 111 | Starting service assembly: test-sa
... | ramework.AutoDeploymentService 648 | Directory: hotdeploy: Finished
installation of archive: test-sa-1.0.0.zip
... | ramework.AutoDeploymentService 664 | Location test-sa-1.0.1.zip no
longer exists - removing ...
... | ramework.AutoDeploymentService 427 | Attempting to remove archive at:
test-sa-1.0.1.zip
... | ramework.AutoDeploymentService 442 | Undeploying service assembly test-sa
... | ework.ServiceAssemblyLifeCycle 207 | Shutting down service assembly:
test-sa
... | ework.ServiceAssemblyLifeCycle 207 | Shutting down service assembly:
test-sa
... | bi.framework.DeploymentService 683 | UnDeployed ServiceUnit test-jms-su
from Component: servicemix-jms
... | bi.framework.DeploymentService 683 | UnDeployed ServiceUnit
test-quartz-su from Component: servicemix-quartz
{noformat}
I've looked through the code base and it seems that the deployment logic is
shared across various places. I see that the DeploymentService is in charge of
restoring service assemblies and it doesn't look like it uses the deploy.xml or
hotdeploy.xml at all. The AutoDeploymentService is in charge of maintaining and
tracking the state of the hotdeploy directories. Seems like the
DeploymentService restore logic should be part of the AutoDeploymentService
class. I also question whether we need the hotdeploy.xml and deploy.xml files.
It seems like this information is partially redundant information to the
working directories that are created for each service assembly (i.e.
data/smx/service-assemblies/XXX). Another suggestion could be to also use
checksums (MD5 or SHA1) to determine if an archive has changed.
As a workaround for now we are just deleting the data/smx directory between
restarts to force the AutoDeploymentService to have a clean state before
startup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
