wso2 / carbon-coordination

carbon-coordination

carbon-coordination's Issues

clearMembershipEvents is called twice when joining a group

Absolute method reference:
org.wso2.carbon.cluster.coordinator.rdbms.RDBMSCommunicationBusContextImpl#clearMembershipEvents(java.lang.String, java.lang.String)

Pending ZooKeeper Implementation

Description:
Currently, only RDBMS coordination is supported in C5 implementation. Implmentation of ZooKeeper coordination is pending

Suggested Labels:
Feature

Suggested Assignees:
@sajithshn

Need a way to check if the current node is the leader

Currently, It is only possible to get the node details of the leader node. Maybe we can return the node ID when joining the cluster group and use that to check if the current node is the leader.

Config location is not correct

Currently, the config is read from $CARBON_HOME/conf/coordinatorConfig.yaml. It should be read from $CARBON_HOME/repository/conf/coordinatorConfig.yaml

Duplicate ClusterCoordinator classes

We can probably get rid of the one in org.wso2.carbon.cluster.coordinator.commons

Persist generated node ID after first node start

Data cleaning will be easier if we reuse the same node ID for nodes.

We can persist in $CARBON_HOME similar to how the pid is persisted

Remove C5 carbon-datasources dependency for version 1.x.x

Implementation based on carbon-datasources, based on C5, needs to be removed to use the coordination component with C4 based products.

modules should be restructured to allow extensions

I propose the following module restructuring to manage multiple coordination strategy implementations effectively.

List of modules,

• org.wso2.carbon.cluster.coordinator.core - This will include the core logic independent of the coordination strategy implementation. This will use a configuration to select between the available CoordinationStrategy implementations. An OSGI service implementation can be used to indicate the availability of the component.
• org.wso2.carbon.cluster.coordinator.rdbms - This component will provide the rdbms based implementation as a OSGi service
• org.wso2.carbon.cluster.coordinator.zookeeper - This component will provide the ZooKeeper based implementation as a OSGi service

Events can be missed in high concurrent scenarios

RDBMS coordination read notifications from MEMBERSHIP_EVENT_TABL. After selecting notifications, those are deleted by the destined node. This would lead delete unread notifications in a high concurrent scenario.

The fix is select notifications with event id and then delete notifications by event id.

Related JIRA: https://wso2.org/jira/browse/MB-1881

Get rid of the ANT build dependency

It seems the purpose of the ant build is to copy coordinatorConfig.yaml file from src/main/config to src/main/resources and create the target directory which we don't have to do.

Build file location:
features/cluster-coordinator/org.wso2.carbon.cluster.coordinator.service.feature/build.xml

Multiple database support for C5 implementation

Description:
Current C5 implementation of RDBMS based carbon-coordination only works with mysql. Need to add support for oracle, mssql and postgresql databases

Suggested Labels:
Feature Enhancement
Priority High

Suggested Assignees:
@Anoukh

Affected Product Version:
carbon-coordination C5 implementation

OS, DB, other environment details and versions:
N/A

Steps to reproduce:
N/A

Related Issues:
N/A

Coordination state should be expired before reelection

This should be done to avoid two coordinators operation in the same cluster group.

Refer the following commit for similar implementation:
wso2/andes@cef1d6a

Database scripts are missing in the feature

Database Scripts for the following DBs should be added,

• MSSQL
• MySQL
• Oracle
• Oracle RAC
• PostgreSQL

REMOVED_MEMBERS_TABLE should be cleared when node is restarted

Currently, only the MEMBERSHIP_EVENT_TABLE is cleared when restarting.

Naming convention of import ranges

Description:
Naming conventions of import ranges is inconsistent in parent pom. All version ranges should end with .range

Suggested Labels:
Minor Fix

An XML configuration should be used for 1.x.x version

Currently, a YAML configuration is used even in the 1.x.x version. For consistency with other Carbon 4 configs, config should be an XML file.