Sometime ago I posted a blog about achieve fault tolerant messaging, in the article I mention using the fabric registry discovery to hide all the IP address and port detail in the client side. With new Fuse 6.2 you will not be able to find this anymore.  So how do we achieve fault tolerant messaging in the new Fuse?

In JBoss Fuse 6.2, we can do it by starting up a MQ Gateway. What it does is it provides a single IP and port to accept connections from clients.  All the individual IPs and Port of the broker are hidden away tothe client, the client only needs to know the IP and port of the MQ Gateway (Default Port: 61616). The gateway will discover all the brokers in the fabric, and no matter what the incoming protocol is, it can be OpenWire, MQTT, STOMP and AMQP. The gateway will see which broker is available in the host specified for the protocol, and connect the client to the broker. If multiple brokers are available in the host group, gateway can dispatch request to them, by this we can achieve load balance. There are 3 different way to do load balance, Random, Round Robin and Sticky.

If any thing goes wrong with the broker a client is connecting, and got disconnected, the gateway will look for another available broker in the group. This gives you high availability to your service.

To startup a MQ Gateway, simply choose the gateway-mq profile to the container.

It will automatically find brokers in fabric, 



I updated my failover demo instead of using fabric registry discovery, I change my application and connect it to MQ Gateway.  In this demo, you will first need to create a broker failoverMS, choose Master/Slave type and use blogdemo as Group.





Click on the red triangle to start provision the brokers. It will take you yo the page to create container for the broker profile.


And will start create number of container you specified in the configuration.


Then we can startup the MQ-Gateway, before we do that, go to the gateway-mq profile and edit the io.fabric8.gateway.detecting.properties file. Change port to 8888 and defaultVirtualHost to blogdemo.



And add the gateway-mq profile to a container, as previously stated.
Let's take a look at the client application, it's written with Camel. Look at the configurations in the Camel route, here you see no matter if it's an OpenWire or MQTT protocol, it is set to tcp://localhost:8888, which is the IP and port of MQ Gateway.

This application send a message to the broker, through OpenWire and MQTT protocol every 5 secs. Deploy the profile "" to a new container.



Go to container console of testcon, you will find the camel routes are running



In the MQ Gateway, you can see the request was dispatched to the broker we have created.
And the messages was sent to broker.






Video can be found here.


The application code can be found here.
https://github.com/jbossdemocentral/jboss-fuse-mqgateway-failoverdemo

Enjoy!
Posted by
Labels: A-MQ Failover MQ Gateway. JBoss Fuse. Fuse.
1

View comments

Quick recap, 

Last article I talked about the study I did among Red Hat customers that makes the jump towards deploying their workloads on hybrid and multi-cloud environments.  These articles are abstractions of the common generic components summarized according to the actual implementations. 

To overcome the common obstacles of going hybrid and multi-cloud, such as finding talents with multi-cloud knowledge. Secure and protect across low trust networks or just day to day operation across the board.
1

Hybrid multi cloud can be a difficult, this is my study of a real customer use case on their journey using GitOps, multi cluster management system and securing dynamic infrastructure secrets.   

Quick recap, 

Last article I talked about the study I did among Red Hat customers that makes the jump towards deploying their workloads on hybrid and multi-cloud environments.  These articles are abstractions of the common generic components summarized according to the actual implementations.

Hybrid multi cloud can be a difficult, this is my study of a real customer use case on their journey using GitOps, multi cluster management system and securing dynamic infrastructure secrets.

Quick recap, 

In my series of articles I went over the study I did among Red Hat customers that makes the jump towards deploying their workloads on hybrid and multi-cloud environments. These articles are abstractions of the common generic components summarized according to the actual implementations.

Hybrid multi cloud can be a difficult, this is my study of a real customer use case on their journey using GitOps, multi cluster management system and securing dynamic infrastructure secrets.   

The Intro, 

More companies are strategizing to be on Hybrid cloud or even Multi-cloud,  for higher flexibility, resiliency and sometimes, simply it’s too risky to put the egg in the same basket. This is a study based on real solutions using Red Hat’s open source technology.
1

Recently I had an opportunity to work with Sanket Taur (IBM UK) and his team on a demo, showcasing how Red Hat products can help speed up innovation with SAP Landscapes. To be honest I was shocked at how little time we were given to create the entire demo from scratch. It’s less than a week. While still doing our day job, having a couple of hours per day to work on it. If this doesn’t convince you..

You want Kafka to stream and process the data. But what comes after you set up the platform, planned the partitioning strategy, storage options, and configured the data durability? Yes! How to stream data in and out of the platform. And this is exactly what I want to discuss today.
1

Getting Started with Apache Camel ? This post is for you. But I am not going to dive into how to write the Camel route, there are plenty of materials out there that do a better job than me. A good place to get started is the one and only Camel Blog, it gives you all the latest and greatest news from the community. If you want to start from the basics, I highly recommend Camel in Action II Book. It has everything you need to know about writing Camel.
2

Introduction: 

Contract first application development is not limited to synchronized RESTFul API calls. With the adoption of event driven architecture, more developers are demanding a way to set up contracts between these asynchronous event publishers and consumers.. Sharing what data format that each subscriber is consuming, what data format is used from the event publisher, in a way OpenAPI standards is going to be very helpful.
6

Serverless should not be optional, but instead it should be there for all cloud native environments. Of course not all applications should adopt serverless. But if you look closer, the majority of the modules in the application are stateless, often stash away in the corner, that are needed occasionally. Some need to to handle loads that are highly fluctuated. These are the perfect candidates to run as serverless.
4

Camel K, a project under the famous Apache Camel project. This project totally change the way developers work with Kubernetes/OpenShift cloud platforms. By automating the nasty configuration and loads of prep work from developers. 

If you are an old time developer like me. I did my best slowly trying to adapt the latest and greatest cloud native “ecology”. It’s not difficult, but with small things and traps here and there. I’ll tell yel’ it's not a smooth ride.
1
Popular Posts
Popular Posts
About Me
About Me
Archive 檔案室
Archive 檔案室
Labels
Labels
Blog of My Friends
Blog of My Friends
Facebook Groups
Facebook Groups
Support a friend
Support a friend
Loading
Dynamic Views theme. Powered by Blogger. Report Abuse.