Feb 21, 2012

JMS Prevent Message Loss

Its a common question that comes in mind while dealing with JMS.
How to guarantee, there is no message loss?
Also how to secure message delivery, or guarantee message delivery.
Some of the considerations are below:
Persistent Message( in case of Queue and Topics):
A message can be persistent or non-persistent.
Acc. to JMS specification, when a message is marked as persistent, the JMS provider must “take extra care to insure the message is not lost in transit due to a JMS provider failure”.
If the message is persistent, message is stored in the data structure representing the Queue(it can be table in database or file, etc. ), otherwise message is stored in memory.
When message is sent over Queue, If a consumer is connected the message will be dispatched to it. If there are no consumers connected the message will remain saved on disk until a consumer connects, whereupon it will be dispatched. If message is non persistent message is saved in memory.  Which means if the Queue Broker or Queue Manager is restarted, the message would be lost.
Durable Subscription(In case of Topics):
A subscription on a topic can either be durable or non-durable. The term durable applies to the subscription, not the topic itself or the messages sent to it. And it applies only to subscriptions on topics, not subscriptions on queues.
If the subscription is open(active), both non-durable and durable behave in same way.
Diff. comes when the subscription is closed. Only durable Client would receives missed messages, when subscription is again open/active.                                                                        
In case of topics, there can be different combinations of persistent/non-persistent  messages and durable/non-durable subscription.
If subscription is durable, then message would be saved if the subscriber is inactive, otherwise not.
If message is persistent, it would be saved on disk otherwise in memory.
So, same message would be saved for durable subscribers, and wont be saved for non durable subscriber.
In case of topics there can be diff scenarios:
Multi Consumer Queue Multi Consumer Queue is a concept some times confused with Topic.  Multi Consumer Queue, is a case when multiple consumers register with a Queue. Message Broker routes the incoming messages to different consumers. Its all the case of load balancing, where one batch of messages is sent to One consumer, and next batch batch is sent to next consumer in line, and similarly batch of messages is sent to different consumer, but same message is not sent to multiple consumers.  Messages are routed to active consumers in order they registered with the broker. Idea behind is the message production rate is much higher, and there is a need of load balancing on the message consumer side. We have a special scenarios to consider, which might relate to message loss. When message production rate is slow, broker might dispatch messages in uneven manner, and some consumers may never receive any message. There should be a backup consumer, if the active consumer fails. And to avoid whole batch of messages.
Message is an entity, and once client delivers the message to Message Broker inside Provider, its role is finished. Message are passed to consumer using the store and forward paradigm. To avoid loosing message in case of Provider failure OR consumer failure, message should be persistent message.   Message can be in many states –                                                                                                    
It might be prepared by Client and not yet delivered to Broker.                                         
Message is routed to Broker by the Message Producer.  
Message is at Broker and waiting for Consumer to consume it.   
Message has been delivered from Broker to Consumer.                
When we make message Persistent or when we make Durable Subscription, we guarantee that message wont be lost from Broker. But message can be in a different state also, OR message is carrying some data or information, which should not be lost. If message is delivered from Broker, it must reach Consumer, it should not be lost in network, and if in case it is lost, there should be re-delivery. 
Guaranteed Delivery –  When we make message persistent, we guarantee that message wont be lost from broker. In case of Topics, we take one extra care that we make durable subscriptions.  We have to take care that Message is not lost on network, or if it is lost in network, we must know and redeliver. Message Acknowledgment is key to guaranteed messaging and ensures that is message is not lost from network while travelling from producer to consumer, it would be re-delivered.
Message Acknowledgment - There are several types of Acknowledgement, and acknowledgement is set on session. Message Acknowledgment has different meaning for Broker and Consumer. Acknowledgment means consumer acknowledges that message is received. Acknowledgement is sent from broker, and also from consumer to broker.
Brokers Acknowledgement( Broker to producer) - Broker received message, stored in memory or data store(in case of persistet message), and accepts responsibility of delivering it to consumer.
Consumer Acknowledgement(Consumer to broker) – Acknowledgment is sent according to the Acknowledgement Mode. In case of AUTO, the session automatically acknowledges the client’s receipt of message. In CLIENT, client has to explicitly send acknowledgement by calling message’s acknowledge method. In DUPS_OK, acknowledgment is sent after consuming particular number of messages( lazy acknowledgement). Message can also be received in TRANSACTIONAL_MODE, where message is received in JTA transaction, and acknowledgement is sent only if transaction commits. If broker doesn’t receives an acknowledgement, it would attempt to redeliver the message, with setting a flag JMSRedelivered on message.
There can be a scenario, where consumer consumes a message, and sends ack., but ack. fails and lost in network, and broker would assume that message is lost and not consumed by consumer, and it would try to redeliver, this can lead to duplicate message for consumer. Consumers should always check for JMSRedelivered flag for identifying the duplicate messages.
Remember, Message Re delivery not guaranteed for more than once.
In a complex architecture, several consecutive operations can be combined under single transaction. We can use the same session to receive a message from a queue and send a message to a topic in the same transaction, if required, programatically. We cn make the session transactional, and perform multiple operations into one atomic unit of work if required. Please find below were it was required to use JMS local transaction for guaranteeing delivery.                                                                                                                 
Scenario – Transfer messages from one queue to another.                                                           Assumption – Two Queues – Queue1 and Queue2, we are going to write a Java program to transfer messages.                                                                                                                            
Remember, Receiving a message form Queue1 and Sending message to Queue2 are two different transactions.                                                                                                
Transaction(T1) – Receive message form Queue 1                                                                         Transaction(T2) – Send message to Queue2.                                                                                  
We need to perform both transactions in XA fashion, means if any one fails, it should be rolledback. Means for any particular message, if any transaction(T1 or T2) fails, it should be send back to Queue1. T1 and T1 should be combined into one transaction. We can use XA resources, but here we are doing it manually(to observe more closely). -
JMSMessageReciver – program to receive message from JMS Queue.                                       MQMessageSender – program to message over MQ.


WebSphere Application Server Profile, Cell, Node, Application Server Basic

WebSphere Application Server is a key SOA building block. We can build a complete SOA application only using WAS. But If we look at the SOA reference Architecture, WAS can be used to develop and deploy Business Application Services. WAS(WebSphere Application Server comes in different packaging with different application server capabilities. Major packages are Base, Express, and Network Deployment.
Network Deployment(WAS ND) package come some unique feature clustering which is not available in other packages. WAS is organized based on the concept of cells, nodes, an servers. All these elements are present in all the packages, and are of most significance in WAS ND. The application server is the run time component under which J2EE application executes. It exists in all packages. In WAS ND we can create clustered and distributed environment, but in Base and Express there can be multiple application servers, but each application server functions as a separate entity.
Profile- Profile is run time instance running in separate JVM instance. Profiles are similar to instances in some application servers. But instances in WAS5 used to have separate configuration files, but used to share some information. WAS6 onwards, profiles were introduced, which used to share core product files, and each profile also had collection of user files. Each profiles created in separate directory, and created using a tool PMT(Profile Management Tool). There are multiple types of profiles. We can say an WAS instance has those features according to defined by the type of its profile. A profile type decorates the WAS instance with features. Different profile types are cell, management, application server, custom, and secure proxy. To deploy and run J2EE application, we need an application server profile, which creates a Stand alone application server.
 Stand alone application server, application server acts as a unique entity. Profile Type “Application Server” contains one application server definition. Multiple stand alone application servers can co exist in same machine, and each one can be admistered by their administrative console. In WAS ND, there can be multiple application servers managed from a central location(deployment manager).
Cluster - A logical group of application servers within same cell, and all running the same set of applications and services is Cluster. Application servers are grouped into Nodes, and each node has a node agent, Node Agents communicate with Deployment Manager, and  Management of Deployment Manager is done by the Administrative Console.  Nodes and Application Servers belong to same cell. Remember, Nodes and Application Servers can be created independently and federated to the cell.
Node, Each application server belongs to a node. Multiple applications servers can be grouped under one node. Node can be assumed to be the physical system on which there are some instances of the application server. There can similarly different machines/nodes. Each node has Node Agent. Node Agent is created when a stand alone node is federated to cell. Node Agent is only included in WAS ND. Node Agents communicate with Deployment manager(One Deployment Manager in one cell, and all node agents of code belonging to same cell).  Deployment Manager is the centralized manager of all nodes. Nodes can also be grouped together into Node Group. There can be multiple node groups under one cell.
So, cell is grouping of nodes. At a min a cell must have one node, but when we create cell, two nodes are created(one for deployment manager and other for federated application server). A Stand alone Application Server exists with one stand alone node, this node exists within a cell, which contains only one node. In WAS ND, we can created an env, where multiple nodes(containing multiple servers) can be managed by one deployment manager. 
Most Important - 
Resource Scopes
First time when we create cell(while installation), two nodes are created, one contains application server(federated) and other contains deployment manager. If we create any resource(like JMS, JDBC Data Source, etc. ) it can exist within different scopes-

1. All (Resource would be visible to everyone)                                                                                
 2. Cell(Top level),   Aug2010Cell01                                                                                            
 3. Node1(containing Application Server) second level,  Aug2010Node02                           
 4. Node 2(containing deployment manager) second level,     Aug2010CellManager01     
 5. Application Server, lowest level, only visible to this application server.  Aug2010Node02, Server=server1                                                                               
In Bold are the names( in my environment, names may differ in yours).
After WAS installation we can create a Stand alone application server, and when we create any resource using Administrative console of this stand alone server, apart from all we have three scopes – cell(top level), node, and server(lowest level). 
In clustered environment, there are multiple nodes within a cell, and there i a deployment manager, which is the central administration point of the cell. Deployment Manager itself runs under a node an communicates with other nodes using their node agents. All the nodes federated to the cell, are managed by single deployment manager.
Multiple Deployment Managers(of different cells), and stand alone application servers, and other administrative agents are managed by Job Manager.  Multiple Stand alone Application Servers can be managed from central point using administrative agents and Job Manager.


Struts1 vs. Struts2 – Difference between Struts1 and Struts2

What is the difference between Struts1 and Struts2?
I believe its very important to understand the difference, even if you are not working on Struts.
Struts2 architecture, design, and flow is probably the best among all web application frameworks today.
You might work for few years and then design an excellent framework, and most probably it would be Struts, or if much better than it would be Struts2.
I am going to continue explore the Struts and Struts2 within few posts.
but starting with some very basic difference between Struts1 and Struts2. Because those who are familiar with Struts1, must know these basic difference, which is big difference in architecture and framework.
Web.xml configuration changes.                                                                   
 Struts1.                                       ActionServlet was the concrete controller for an application.The Controller was responsible for intercepting and translating the User Input into Actions to be performed by the model.                  
 Struts2                                       FilterDispatcher executes action by consulting the ActionMapper and determining if the requested URI should invoke action. If mapper indicates proper action is invoked.      Filter also serves common static content.                           
  Configuration file Changes:                                                               
  Struts1                                                There was struts-config.xml.Configuration file is listed as initialization parameter to the action servlet in web.xml.  Parameter can be extended to specify multiple config initialization parameter.                                                               
 Struts2                                                     We have struts.xml.There is no initialization parameter for struts.xml. struts.xml needs to be in the class path. Struts.xml has file inclusion facility.                                                 
Namespace separation between Struts Action                                                                
Struts1                                                                   .do                                                                
Struts2                                                                .action.
A difference in the action, also means that Strusts1 and Struts2 can both co extst within the same application.  Which also means actions are the good point to strat the migration from Struts1 to Struts2.
Now, those who have worked over Struts, and those who are aware of the Action classes in Struts, for them there is a big diff. between Struts1 action and Struts2 action:

All Actions have to extend the Action class. Single Action instance is created. So, all actions have to thread safe. Action has to be thread safe, so all objects are passed as parameter.The name of the first method that is invoked for the processing of action, must be execute(), however DispatchAction class can be used to re-route the action to different method within the same action.Return of the execute() method is ActionForward, generated using the methods of the ActionMapping class.                                                                         
Action class doesn’t need to extend any class or interface.An action instance is created for each request. Its not shared and its discarded after the request has been completed.Its not mandatory to have the method name as execute(). Any method with proper signature can be invoked through configuration.No objects as parameters are passed to the method. Objects are available to the method using Dependency Injection.Return object of the method is String. Helper interface Action is available for String constants like: “success”, “error”, etc.
The difference in the Action classes also leads to one confusion, of how is the HttpServletRequest, request parameters, Mappings, etc. available to the Action class in the Struts2.
A sample Action class in Struts1 was something like:
public class RemoveEntryAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception {
Service service = new Service();
String id = request.getParameter(“id”);
return (mapping.findForward(“success”));
As we can see that id is fetched from the request. Service is a Service class or it can be a facade.
RemoveEntry is one action, Similarly we would have multiple Action classes for different actions.
Actions like making new entry, updating entries, finding entries, etc.
And all the action classes related the Entry would be similar, in the sense, all would retrieve id from the HttpServletRequest, instantiate Service, and call some method of the Service class.
This is how things were in Struts1.
In Struts2, since a new object would be created for each request, we can have class level variables, we can have some setter methods, and above all we can write all the actions within the same class.
So, we can have a class level variable like Service( for Service class), and id( for id retrieved from HttpServletRequest), we can have setter methods for these class level variables.
Assume, we want to write the Action class like this:
public class EntryAction {
private int id;
private Entry entry;
private Service service = new Service();
private HttpServletRequest request;
public void setServletRequest(HttpServletRequest httpServletRequest) {
this.request = httpServletRequest;
public void setId(int id) { this.id = id; }
public void prepare() throws Exception {
if( id==0 ) { entry = new Entry(); }
else { entry = service.findById(id); }
public Object getModel() { return entry; }
public String save() { service.create(entry); return SUCCESS; }
public String update() {
return SUCCESS;
public String remove() {
service.delete(id); return SUCCESS;
public String execute() {
return SUCCESS; }
But the whole idea would be defeated, and we wont be achieving anything if we are going to call the setters.
When new instance should be created for each request, then variables should be set automatically, possibly by the container. And this is how it should be. And this is how it is done.
And this is where Dependency Injection comes in.
To use dependency injection, we need to implement several interfaces.
In fact, what all features we need, we need to implement corresponding interfaces.
To make our Action class to be HttpServletRequest aware, we need to implement and Interface “ServletRequestAware”.
Next, if we have something like init, or postContsruct thing, we can have a prepare() method.
prepare() method would be executed before the execute(or any action method).
We need to implement “Prepeable” interface for that.
We need to apply changes to the model object, and for that we need to implement “ModelDriven”.
And implement getModel() method.
Instance variable in the Action classes is matched with request parameter, and if there is any match, then instance variable is set automatically. So, if the HttpServletRequest contains a parameter named “id”, and Action class has a variable names id, then when the Action class would be instantiated, its id variable would be populated with value of the id in request parameter. Now, remember this is a optional feature, and its not happens by default. Dependency needs to be injected.
We must inform the container that we need this feature. And there should be an interceptor, who is going to do this work.“ParametersInterceptor” is going to do this work
public class EntryAction implements ModelDriven, Preparable, ServletRequestAware {

© Technology Development with Java background | All rights reserved.
Blogger Template Crafted by pipdig