Yes this seems to be an issue and here we are storing stream definitions in governance registry which is accessible by many clusters, which is making this process even worse.
@Regisry,ESB folks so you have any solutions for this ? Regards Suho On Thu, Feb 19, 2015 at 11:06 AM, Ayash <[email protected]> wrote: > Hi All, > > I think we have to broadly discuss the $subject since this is a bit > architecturally problematic even in the standalone products and also in the > clustered ones. > > In CEP, we started developing cApp deployer which is released with the CEP > version 4.0.0-m2. In that implementation, saving the stream definitions in > the registry courses the following issue, > > Suppose two cApps consisted of the same stream definition with the same > name and the version. (In both stand alone product mode or clustered mode, > this problem is there). While the first is being deployed and streamdef > packed is also being deployed and while the second is being deployed, the > streamdef again being deployed but no error occurs since there are no > conflicts of two streamdefs. But, once the one of these two is going to be > undeployed, the streamdef is being deleted, but, still the other cApp > expecting the streamdef to be in the registry yet, but, it is not there > anymore. > > As a solution for this, we started counting how many streamdefs get saved > thru the cApps. Here, once the cApp deploys the stream definitions, it > increases the count and once cApp undeploys, it decreases this count. And > once the product is being started, it identifies the cApp deployed > streamdefs and remove them all. > > Here, looks the problem is only solved partially. Because, this solution > looks good while we work with a stand alone product. But, how do we work > with a cluster? if some node in the cluster gets restarted, all the cApp > deployed streamdefs are getting deleted again. > > If we keep everything in-memory without having them persisted in > somewhere, there is no problem like that. But, persistence is a must in > clustering products. So, we have to have some generic solution for the > deployable artifacts. > > IMO, the above solution works, if we can have a worker manager cluster > where all the nodes in the cluster having a sense, if it is a worker node > or a manager node. And then, while only starting manager nodes, already > deployed streamdefs are being deleted, but, no worker is having a privilege > to delete them. > > Or else, the user should not pack the car files with the same streamdef > name and the version. And we give some tool to the user to know if the > streamdef name and the version is available to pack it in a car file. I > don't know how good this solution is, while working with customers. > > I just got the CEP stream definitions as an example to describe this > issue. I suppose that the same issue is there in the other products also > while deployables need to be persisted. > > Thanks, > -Ayash > > -- > Ayashkantha Ramasinghe > Software Engineer WSO2, Inc. > email: [email protected] <[email protected]>; > TP: +94 77 7 487 669 > -- *S. Suhothayan* Technical Lead & Team Lead of WSO2 Complex Event Processor *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
