Hi,
I've fixed most of these cases we discussed here. To summarize;
- Registry exceptions should always be thrown from persist() method and
should be handled by the methods that are calling it
- If service name, cluster id or member id is not found in the Topology, a
RuntimeException should be
A good finding Dinithi! May be you can fix this for 4.1.4.
Thanks
On Wed, Sep 30, 2015 at 9:22 PM, Dinithi De Silva wrote:
> Hi Akila,
>
> Thank you for bringing this up. +1 for this as this would lead to an
> unrecoverable state and we can not even find out where it went wrong.
>
> I found ano
Hi Akila,
Thank you for bringing this up. +1 for this as this would lead to an
unrecoverable state and we can not even find out where it went wrong.
I found another place in CloudControllerServiceImpl class which we need to
fix.
private void onClusterRemoval(final String clusterId) {
ClusterCont
Yes indeed! As I found the problem is in CloudControllerUtil class:
public static void persistTopology(Topology topology) {
try {
RegistryManager.getInstance().persist(CloudControllerConstants.TOPOLOGY_RESOURCE,
topology);
} catch (RegistryException e) {
String msg = "Fail
+1 for handing these dependent operations as atomic in order to avoid
inconsistency. It is a good thought.
Better have the same approach for application model also as it has to
update monitor hierarchy and application model at the same time.
Thanks,
Reka
On Tue, Sep 29, 2015 at 1:57 AM, Akila Ra
Hi,
This is to bring your attention to possible inconsistency that could arise
due to rare edge cases. For an eg: If you follow the piece of code at [1],
handleMemberTerminated can return without successfully removing a member
from topology but the next step will get executed which is to remove th
