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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to