Hi all, Currently BPS uses registry to persist the uploaded BPEL archive, deployed versions, package specific properties like MD5 hash, deployment status (undeployed/deployed/failed/updated) and failed reason if a failure occurs. Due to restrictions in using the config registry like having only one write node making it unable to deploy processes in multiple nodes, I'm introducing a meta data file per package that will be in the $CARBON_HOME/repository/deployment/server/bpelmetafiles directory. This file is similar in format to the deploy.xml, is synced via deployment synchronizer and can be picked up by a BPELMetaDataDeployer.
I've now implemented support for writing to these files when Deployment details are modified at the runtime via the Deployment Descriptor Editor in the front end, and retrieving them at the server startup to populate each process' configuration instead of using the registry. But in a clustered environment, this approach can cause problems because of BPEL versioning concept. For instance: Say there's a clustered setup with 2 BPS nodes. A user uploads a BPEL zip to Node 1. Since BPEL deployer takes few seconds to deploy, before its been deployed in Node 1 and meta file is created, it's synced to Node 2 via the deployment synchronizer. When the Node 2 tries to deploy the BPEL zip it does not find any metafile so it creates a new version. This leads to a situation where 2 identical BPEL packages are deployed in the cluster with different versions, which is not the expected behavior. Your feedback on dealing with such a scenario is very much appreciated. -- *Keheliya Gallaba* Software Engineer; Integration Technologies Team; WSO2 Inc.; http://wso2.com, *email: **keheliya [AT] wso2.com* <[email protected]> *mobile: +94 71 551 8881* *blog: **http://galpotha.wordpress.com* <http://galpotha.wordpress.com>* twitter: **http://twitter.com/keheliya* <http://twitter.com/keheliya>* linked-in: **http://lk.linkedin.com/in/keheliya*<http://lk.linkedin.com/in/keheliya>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
