I think option 1 would work because you have to use andes client as a dependency to initiate individual connections with message broker. Also, OSGi component should wrap message publishing service and provide it to the caller. Inside the OSGi component, you can have logic to load balance messages.
On Fri, Aug 19, 2016 at 4:25 PM, Sidath Weerasinghe <sid...@wso2.com> wrote: > Hi all, > > > > Message Broker provides means to horizontally scale between nodes. The > client which communicates with the broker is notified on the availability > of the broker nodes in the cluster via JMS connection URL, which allows > defining of a failover string (the list of IPs of the broker nodes > separated by comma). Also, When integrating with other products (eg- ESB, > DAS); we specify the list of nodes in JNDI.properties file in the > following manner. > > connectionfactory.QueueConnectionFactory = amqp://admin:admin@clientID/carbon > failover='roundrobin'&cyclecount='2'&brokerlist='tcp://IP1:5672 > retries='5'&connectdelay='50';tcp://IP2:5672?retries='5'&con > nectdelay='50';tcp://IP3:5672?retries='5'&connectdelay='50'' > > Configurations to the JNDI.properties > > > The above approach would require the user to manually list out IPs of the > broker nodes to the client connection string or the application context, > which in fact limits the user experience and achieving the scalability > goals in the following way, > > > 1. > > The user/developers having to manually list out the IPs in the > connection URL could be prone to error. > 2. > > The change of IPs of the broker nodes would require reconfiguring and > restart the client applications connected to it. > 3. > > The approach would also be a blocker for auto scaling between broker > nodes. (Since addition of IPs needs to be manually reflected in the client > application.The manual process would only address failover between broker > nodes. This limits the client applications to load balance between the > broker nodes) > > > > > How existing system works > > > Proposed solution > > > > - > > Specify an admin service inside the MB. where, the broker clients > could query the service to get the list of IPs in the broker cluster. > - > > Via calling an admin service which is implemented inside the MB; can > discover available MB nodes in the cluster. > - > > Periodically calling this service we can get the dynamically adding MB > node IP addresses and can remove disconnected IP addresses from the list. > So it will always shuffle the IPs and provide it for the client. > - > > According to the live MB node IP address, I will create the > connections and use this connection as round robin fashion or use disruptor > for load balancing purpose. > > [image: pic 2] > > > > > > > > > > There are several ideas for doing this. > > 1. Build separate OSGI component > 2. Modify the Andes client according to the above scenario. > > Any ideas? > > -- > Thank You, > Best Regards, > > Sidath Weerasinghe > > > *Intern* > > *WSO2, Inc. * > > *lean . enterprise . middleware * > > > *Mobile: +94719802550 <%2B94%20777764144>* > > *Email: *sid...@wso2.com <ja...@wso2.com> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Indika Sampath Senior Software Engineer WSO2 Inc. http://wso2.com Phone: +94 716 424 744 Blog: http://indikasampath.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
