Patent Publication Number: US-8990320-B2

Title: Method, apparatus and computer program for message handling

Description:
FIELD OF THE INVENTION 
     The invention relates to message processing and more particularly to a message consumer becoming inactive. 
     BACKGROUND OF THE INVENTION 
     A popular configuration for Message-oriented-Middleware (MoM) is to collocate a queue manager with each instance of a client or server. In this context, a client or a server could be a single message-consuming application but could equally be a platform that runs multiple different applications, some or all of which use the MoM; examples include IBM® CICS®, IMS™; WebSphere® Message Broker and WebSphere Application Server (WAS). (IBM, CICS, IMS and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.) 
     Collocation of a queue manager with each client/server in this way is often chosen because it allows a sender to continue using the MoM even when a receiver&#39;s communication is temporarily unavailable; it may also be chosen as a way to provide greater MoM capacity, or for other reasons. 
     A potential problem with this collocation happens when the receiver (i.e., client or server) is inactive whilst its collocated queue manager is active. This can happen, for example, during start-up when the queue manager start-up completes much more quickly than the receiver start-up, or if the receiver suffers a software failure which does not causes a queue manager outage. In this situation the MoM, typically continues to deliver messages to the queue manager while the receiver is inactive. This is sometimes undesirable, especially where the receivers are servers that are clustered so that the preferred behaviour is for the MoM to deliver messages to queue managers collocated, with active receivers and not to queue managers collocated with inactive receivers. 
     SUMMARY OF THE INVENTION 
     According to a first aspect, there is provided a method for refusing to process messages from a sender at a queue manager associated with a receiver when the receiver is inactive, the method comprising: identifying whether a first destination has been selected, the first destination providing an indication of whether the receiver is active; responsive to identifying that the first destination has been selected, determining using the first destination whether the receiver is active; responsive to determining that the receiver is inactive, refusing to process messages at a second destination, wherein messages at the second destination are intended for the receipt by the receiver. 
     Refusing to process messages at a second destination, may mean that the queue manager does not even accept any messages, for that second destination. It may alternatively mean that it recognizes that a message is for the second destination and routes that message elsewhere. Another possibility is that the message is accepted at the second destination but not allowed to remain at that second destination; in other words is rerouted. Messages therefore, preferably do not build up at the second destination when the receiver receiving messages from that second destination is inactive. 
     Determining whether the receiver is active, may be performed periodically. 
     “Associated with” may mean “collocated with”. 
     In a preferred embodiment, in order to determine whether the receiver is active, it is determined whether the first destination is open for input. 
     In one embodiment, the receiver is a server associated with the queue manager. 
     In one embodiment, the receiver is a receiving application. 
     In one embodiment, an administrator is able to select the first destination. 
     In another embodiment, an indication is received from the receiver as to which first destination should be selected and the first destination is then selected based on the received indication. For example, the receiver might indicate that the receiver is a particular type of server (and then the appropriate destination can be deduced) or an actual destination might be suggested. 
     In one embodiment, responsive to determining that the receiver is inactive, informing a queue manager responsible for forwarding messages from the sender and destined for the receiver that said forwarding queue manager should refrain from sending said messages destined for the receiver (i.e. messages destined for the second destination.) The sending queue manager can then be informed when said forwarding queue manager can continue sending messages destined for the receiver. 
     In one embodiment, responsive to determining that the receiver is inactive, informing a queue manager responsible for forwarding messages from the sender and destined for the receiver that said forwarding queue manager should refrain from sending said messages for a period of time. 
     In one embodiment, refusing to process messages means disconnecting from a connection to a queue manager responsible for forwarding messages from the sender and destined for the receiver. 
     In one, embodiment, one queue manager is associated with multiple receivers. 
     Each receiver may have a separate destination selected, each destination providing an indication of whether that receiver is active. 
     According to a second aspect, there is provided an apparatus for refusing to process messages from a sender at a queue manager collocated with a receiver when the receiver is inactive, the method comprising: means for identifying whether a first destination has been selected, the first destination providing an indication of whether the receiver is active; means, responsive to identifying that the first destination has been selected, for determining using the first destination whether the receiver is active; means, responsive to determining that the receiver is inactive, for refusing to process messages at a second destination, wherein messages at the second destination are intended for the receipt by the receiver. 
     The invention may be implemented in a computer-readable storage device having encoded thereon program steps for performing the method of the invention. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A preferred embodiment of the present invention will now be described, by way of example only, and with reference to the following drawings: 
         FIG. 1  is a block diagram illustrating a computer system in which the present invention, in accordance with an embodiment of the present invention, may operate; 
         FIG. 2  is a flow diagram of a method for refusing to process messages from a sender at a queue manager associated with a receiver when the receiver is inactive in accordance with an embodiment of the present invention; and 
         FIG. 3  is a block diagram showing logical components of a computer system in accordance with an embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  illustrates a computer system in which the present invention, in accordance with a preferred embodiment, may operate. A client computer  5  comprises a plurality of applications  20 ,  30 . The applications  20 ,  30  are stored on a memory (not shown) and executed by a processor (not shown in operative association with the memory. One of the client applications  20  requests that an application  50  on a server computer  15  carry out some work on behalf of the client. The application  50  is stored on a memory (not shown) and executed by a processor (not shown) in operative association with the memory. 
     Communication between the client  5  and the server  15  occurs using messaging Middleware  25 . Messaging middleware (for example, IBM&#39;s WebSphere MQ product) comprises a queue manager  10  collocated with the client  5  and a queue manager  40  collocated with the server  15 . Messages are sent by a sending application (e.g. application  20 ) to one queue manager  10 , transmitted to the other queue manager  40  and then retrieved by a receiving application (e.g. application  50 ). 
     Each queue manager comprises program instructions stored on a memory (not shown) and executed by a processor (not shown). The memories and processors may be the same memories and processors of the respective client and server or may be separate memories and processors. 
     As alluded to previously, a problem can occur when the receiving server  15  is unable to retrieve messages from its collocated queue manager  40 . This might be because an application hosted by the server fails or because the server itself fails. Either situation can cause a problem because the queue manager  40  may be unaware of such a failure and will continue to receive messages from queue manager  10  which are ultimately destined for server  15 . 
     There are various possible partial solutions to this problem. One partial solution is to set a maximum queue depth. This has disadvantages that include that it can be difficult to choose a good value. Note that the queueing mechanism is intended to allow messages to build up during transient periods of heavy load (but not when a server is actually down). It may be some time before a queue hits its maximum and the receiver may already have been down for some time. Also, with some message systems, the maximum queue depth only works when there is no dead-letter queue. This is not always, satisfactory. For example, customer may want incorrectly formatted or addressed messages to be put on the dead-letter queue. The maximum queue depth only works when there is no dead-letter, queue because otherwise messages may get delivered to the dead-letter queue simply because the main queue is full. This doesn&#39;t provide an indication to the queue manager that the receiving application is down. 
     Another partial solution is to use a script (or other automation) that health-checks the server and activates or deactivates the queue manager accordingly. (IBM WebSphere Application Server provides heart beat technology which could be used perform such health-checks.) This has disadvantages that include that sophisticated health checks are typically both complex and very specific to the server type and may require custom code. A simple and general solution is preferred. Also, it is preferable to avoid forcing the customer to develop scripts or other automation technology. An out-of-the-box solution is preferred. 
     This problem is addressed as described hereunder with reference to  FIGS. 2 and 3  which should be read in conjunction with one another. 
     An administrator of the messaging middleware is now able to select (using selector component  200 ) a “test point” destination. This could be a queue, publish/subscribe topic (if the queue manager supports pub/sub) or other destination. The administrator knows which server(s) is collocated with the queue manager and selects a queue for which they know there is a high likelihood that when the server is active, the server will, be using that queue. In other words, the administrator selects a queue which should be open for input when the server is active. In general, this will be an existing destination so that no changes are required to the server, configuration. By way of example, this might be the control queue for IBM&#39;s WebSphere Message. Broker product or the CICS bridge input queue for IBM CICS. 
     A test point is identified (if configured) by the identifier component  210  at step  100 . The queue manager then periodically determines at step  1  to whether the server is looking at the test point using the determiner component  220 ; it is already possible for a queue manager to determine whether a queue is open for input (e.g. using the IPPROCS attribute in WebSphere MQ) and thus the queue manager is able to determine whether the server has this test point “open” in order that messages may be put to and got from that test point. In terms of the period at which a determination is made at step  110 , every tenth of a second might be acceptable. The period depends on how quickly the system is expected to notice that there is a problem and how long one would expect it to fake to restart the server. If thousands of messages a second are being sent, then a thousandth of a second or less might be better. It would also be possible to have, the queue manager monitor the message rate and determine a sensible default interval itself. 
     If there is a “test point” destination configured, then the queue manager rejects messages (Rejector component  240 ) when the “test point” destination is not open for input (step  130 ) and accepts messages (Acceptor component  230 ) when the “test point” destination is open for input (step  120 ). 
     One way of rejecting messages is for the server queue manager  40  to break its connection with the client queue manager  10 . This may be achieved, for example, by disconnecting from the incoming tcpip socket. If the messaging middleware is WebSphere MQ then the receiver channel state (stopped or started) is preferably modified to break and re-connect the client and server queue managers. Other methods are possible, for example, by preventing messages from being put to a queue (e.g. Put-Inhibited state in WebSphere MQ), but using the channel protocol to disconnect and re-connect the channel is simple to implement without requiring any significant new capabilities or protocols to be implemented, it also allows queue managers which implement the solution disclosed to exploit the solution whilst coexisting with legacy queue managers. 
     It would equally be possible for queue managers that are rejecting messages to indicate to the sending queue manager that they should try again later (perhaps after a specific interval) or for the receiving queue manager to indicate when it is ready to accept messages again. 
     Whilst the use of only one test point per server has been discussed, it would be possible for each application hosted by the server to have its own test point. In this instance, each application would have its own set of queues. Thus it would be necessary to configure the middleware system in such a way that only access to a particular subset of queues is disabled. In WebSphere MQ, for example, it is possible to configure a queue manager such that there is a channel, per subset of queues rather than one channel per queue manager. 
     In the example given, there might still be a test point for the server as a whole. Configuration of a test point per application would mean that the queue manager would be able to tell when an individual application is no longer receiving messages. 
     In one embodiment, there is a single queue manager collocated with multiple servers. In this example, each server has a separate receiving channel such that it is possible to disable access to a particular channel in the event of a problem with the relevant server. 
     It should be appreciated that whilst the present application is described in terms of a test point configured with respect to the server&#39;s collocated queue manager, it would equally be possible to configure a test point for the client&#39;s collocated queue manager (e.g. if messages were flowing in the direction of the client.) 
     It should further be appreciated that although test points are described as being configured manually by an administrator, some level of automation would be possible. For example, the server may inform the queue manger that it is of a particular type and a lookup table may then be used to determine an appropriate queue to act as a test point. Alternatively, the server may indicate to the queue manager which queue it should configure as a test point 
     It should additionally be appreciated that whilst the present invention has been described in terms of a queue manager and queues. The term “queue manager” is meant to cover any message routing component with the functionality to store messages before transmitting them to a receiver asynchronously. Queues are also not the only option, but rather any message destination such as a pub/sub topic. 
     Further, whilst a queue manager will typically be collocated with a client (as shown in  FIG. 1 ), the server queue manager may not communicate directly with the client queue manager. There may be an additional queue manager in between the server and client queue managers and the additional queue manager may, for example, be told to stop sending messages. That additional queue manager may then reroute messages intended for the inactive receiver elsewhere. 
     It should be appreciated that a queue manager which is collocated with a server may, have the choice of several servers and could then choose not to queue messages for a server that is inactive. 
     The specification indicates that a queue manager is collocated with a client or a server. This may mean located within the same machine. However collocation is not intended to be a limitation of the present invention and a queue manager may simply be associated with a sender or receiver. 
     It should be appreciated that one test point may be used to determine whether to accept messages onto any queue within a set of queues managed by the queue manager. The set may be all queues managed by that queue manager. 
     The present invention may be implemented by hardware or by combinations of hardware and software. The present invention may be implemented in a computer system in a collective or distributive manner, where in the distributive manner, different parts may be distributed in a plurality of interconnected computers. Any computer system or other apparatus suitable for implementing the method as depicted herein is suitable. A typical combination of hardware and software may be a general purpose computer system with a processor, memory, and a computer program. When the program is loaded onto the memory and executed by the processor, it controls the computer system to implement the method of the present invention and constitute the apparatus of the present invention. 
     The present invention may also be embodied in the computer program product which comprises a tangible computer-readable storage medium with program instructions encoded thereon comprising all features capable of implementing the method as depicted herein and may implement the method when loaded to the computer system. 
     Although the present invention has been specifically illustrated and explained with reference to the preferred embodiments, those skilled in the art should understand various changes thereto in form and details may be made without departing from the spirit and scope of the present invention.