Ravindra Ranwala's Blog

INTRODUCTION In general Message Processor is used to achieve guaranteed delivery where messages sent to the JMS queue never get lost even though the back end is down. In case of a failure of the backend, the message processor keeps on retrying sending message to the endpoint a specified number of attempts (defaults to 4) and deactivates itself afterward. It never removes the message from the queue until it is dispatched to the backend successfully. Also message processor ensures in order delivery of messages to the backend. In this article I am going to explain you Message Processor coordination support in WSO2 ESB where we go a step beyond in order to achieve high availability and scalability . Coordination support of the Message Processor comes into play when you run it in cluster mode. Therefore we need to have a cluster setup with one manager and two worker nodes with us to move on further. You may refer my article [1] to create a cluster setup which is a necessary prerequisite

INTRODUCTION In production environments, services are clustered in order to scale up applications, achieve high availability or to achieve both. By scaling up, the application supports a larger number of user requests and through high availability the service is available even if few servers are down. To support balancing of load among these servers, a load balancer is used to distribute requests among the nodes in the cluster. The nodes that receive this incoming traffic are a set of backend worker nodes in a worker/manager separated cluster. The worker/manager setup clearly separates the concerns/responsibilities, where the manager node is responsible for management related activities such as creating, updating and deleting synapse artefacts. The workers are responsible for serving client requests. In this article I will elaborate the steps required to create a WSO2 ESB worker manager cluster without a load balancer. In a production setup load balancer becomes handy, bu