Hi All, We are currently working on $subject, with the requirement to remove Hazelcast based implementation in the scheduling of ESB tasks based on ntask.
In ESB we have adopted ntask based implementation for polling inbound endpoints, message processors and scheduled tasks as follows. - Polling inbound endpoints - if coordination is set to true → ntask based implementation, if not → background thread ( InboundRequestProcessorImpl <https://github.com/wso2/carbon-mediation/blob/master/components/inbound-endpoints/org.wso2.carbon.inbound.endpoint/src/main/java/org/wso2/carbon/inbound/endpoint/common/InboundRequestProcessorImpl.java#L66> ) - Scheduled Tasks and Message Processors - purely ntask based → TaskManager either Standalone or Clustered With ntask - final scheduling in a cluster happens via the ClusteredTaskManager which calls methods made available via the AbstractQuartzTaskManager which in turn calls org.quartz.Scheduler methods. ntask uses Hazelcast for coordinator election and also uses the Hazelcast distributed executor service (IExecutorService) with task scheduling calls, to schedule tasks on specific members. Following an offline discussion [1], it was decided to completely remove Hazelcast from ntask and introduce Quartz's own clustering mechanism via its JDBC-JobStore [2], which we will be integrating with ESB/EI. Please find the architecture@ discussion for ntask at [3]. *Requirements and Design Decisions for ESB* At an offline discussion with the EI team the following decisions were made with regard to ESB specific requirements: - With the current architecture we schedule the task on all nodes in the cluster, with the same name, but execution is done only by one node. However in a graceful shutdown scenario, when a node leaves it would delete the task, resulting in a deletion from the database too. This needs to be prevented with ESB tasks based on ntask, since they are scheduled by the same name and the single task by this name needs to remain in the database for another node to pick it up and reschedule it. - Since we do not delete the task when nodes leave, there could be irrelevant tasks when nodes come back up. The tasks that are scheduled anew should thus override the previous tasks. But in some scenarios, such as with message processors we would need to preserve the state and resume. - If correctly configured, artifacts will be shared across the nodes - thus we can assume undeploying from one node is done expecting undeployment from the other nodes too. Feedback and suggestions would be appreciated. [1] "Updated Invitation: RDBMS based Coordinator Election for EI/ESB - Design Review @ Tue Aug 22, 2017 4pm - 5pm (Maryam Ziyad)" [2] http://www.quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigJDBCJobStoreClustering.html [3] "[Architecture] Introducing Quartz's Clustering Features in ntask" Thank you, Maryam -- *Maryam Ziyad Mohamed* Software Engineer | WSO2 [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
