Abstract:
There is disclosed a method, apparatus and computer program for an application instance to request attachment to a queue partition on a messaging server within a plurality of messaging servers, each messaging server holding at least one queue partition, the set of queue partitions together forming a single queue. An application instance requests attachment to a queue partition, the request requesting exclusivity with regard to other application instances having a common identifier. Responsive to an indicating that the request has been successful, the application instance interacts with the queue partition.

Description:
FIELD OF THE INVENTION  
       [0001]    The invention relates to distribution of applications across messaging servers. 
       BACKGROUND OF THE INVENTION  
       [0002]    In a clustered messaging architecture it is common to have a virtual ‘single’ queue of messages distributed across a cluster of multiple messaging servers. In such an architecture, each server owns a subset of messages for that single queue. Each subset of messages typically exists on a partition of the single queue. It is also possible that only a subset of the clustered servers are running at any one time. 
         [0003]    It is important to achieve an optimal transmission and/or consumption of messages from a partitioned queue. The invention will however be described in terms of consumption of messages for ease of explanation only. 
         [0004]    If there are multiple applications (or multiple instances of a single application; the description is intended to encompass both variations), all consuming the same type of messages, with each application being capable of consuming all messages on a single partitioned queue, then there should be an even distribution of applications (application instances) across all messaging servers that own a partition of the queue, i.e. at least one application being connected to each of these servers. 
         [0005]    There may on the other hand exist multiple applications consuming different types of messages with each application comprising multiple instances. In this case, there should be an even distribution of an application&#39;s instances across all the messaging servers that own a partition of the queue, i.e. at least one instance of the application being connected to each of these servers. In this way it is ensured that messages of the type applicable to the application will get consumed from each queue partition. Note, applications can be consuming according to some property of a message or they could be selecting a particular type of message based on the value of some header or pay load content—i.e. via a filter. 
         [0006]    Optimal distribution of application instances typically becomes a problem if there are not many application instances. If you have a large number of application instances (orders of magnitudes more than the number of partitions) then their distribution is likely to he reasonably even across the partitions no matter what distribution mechanism is used, for example a simple random choice of partition by the application or a round-robin distribution by a number of distribution points. The fewer instances of the application that are attaching, the less likely it is that using a simple distribution mechanism will result in an even distribution. Particularly where there are only a few application instances (about the same number as there are partitions) then it becomes critical to ensure that their distribution is even (ideally at feast one application instance attached to each partition). 
         [0007]    Each application will consume a particular type of message from a single partition and an even distribution therefore means that messages will not be left marooned on a queue partition due to the absence of an application consuming messages of that type. 
         [0008]    Correctly coordinating the distribution of clients across multiple servers is not so difficult if all the applications initially go to a single point that can coordinate these applications. Unfortunately the reasons for having multiple servers is to prevent a single point of failure and to balance the work load across them, so having all the applications communicate with a single point is an obvious bottle neck. So when there is not a single point coordinating all the applications, the ability fur any one server to know where all the applications are connected is lost. 
         [0009]    A simplistic example is now given in which there are four partitions and four instances of an application attaching; 
         [0010]    For a single distribution point using round-robin distribution:
   partition 1: app instance 1   partition 2: app instance 2   partition 3: app instance 3   partition 4: app instance 4   
 
         [0015]    When you have two round-robin distribution points and applications 1 and 2 go to the first distribution point and 3 and 4 go to the second for distribution, the outcome might be as follows:
   partition 1: app instance 1 and 3   partition 2: app instance 2 and 4   partition 3: none   partition 4: none   
 
         [0020]    If there is a single distribution point allocating connections to partitions there is still the problem that the distribution point must know the intentions of each application, distinguish it from other applications and recognise other instances of the same application. Generally there are many different applications attaching to such servers, therefore being aware of them all becomes a difficult and potentially costly (performance and resource) operation. 
         [0021]    So using a similar example where there is no knowledge of individual applications, this time with a second application, again with four instances attaching to the same partitions, where the attach order is application 1, application 2, application 1, application 2 etc.:
   partition 1: app 1 instance 1, app 1 instance 3   partition 2: app 2 instance 1, app 2 instance 3   partition 3: app 1 instance 2, app 1 instance 4   partition 4: app 2 instance 2, app 2 instance 4   
 
         [0026]    Here it can be seen that application 3 is only attached to partitions 1 and 3 and application 2 to partitions 2 and 4. So any messages for application 1 going to partitions 2 or 4 will not be processed. 
         [0027]    There are a number of existing ways to solve to varying degrees the problem of evenly distributing application instances: 
         [0028]    It is known to manually configure each instance of an application to connect to each server. This is very restrictive in that each instance of the application now has a reliance on its configured server being available for it to consume any messages; if also ties the application&#39;s configuration tightly to the architecture of the messaging servers. If the architecture changes, the application&#39;s configuration also has to change. 
         [0029]    Some messaging systems provide a solution whereby any application attempting to connect to a cluster of messaging servers will be directed to one of the servers based on a round-robin distribution by one or more ‘bootstrap’ servers. The downside of this is that the distribution applies to all applications attempting to attach to a server in the duster, with no recognition of multiple instances of the same application. This can result in a fair distribution of ail applications connected to the servers; but, in a worse case scenario, it is possible for all instances of the same application to be connected to the same server, resulting in only a single partition of the queue being consumed from by that application. Since an application may be singularly responsible for a particular type of message, this could prove problematic. Further application instances can detach themselves and the bootstrap servers would not have this knowledge to apply when allocating a new application instance to a queue partition. 
         [0030]    It is also known to statically configure a queue partition to only allow a single consuming application to be attached at any one time. If a partitioned queue is configured in such a way, the consuming application can connect to each server in the cluster in turn and attempt to attach to the queue partition local to that server. If they succeed in attaching then they know they are the only consuming application on that partition; if they fail then they attempt to connect to the next server and try again until they find an available partition. This ensures that each partition has at most one instance of the application at any one time. The downside is when there are more instances of the application than available partitions of the queue, some instances of the application will be left without a queue partition from which to consume. It also relies on the fact that there are no other applications consuming from the same queue partitions (i.e. applications that are not instances of the same distributed application). Another downside is that the queue must be statically configured to only allow one consumer per partition. 
         [0031]    It is also known to allow an application to specify, at runtime, if they require ‘exclusive access’ to a queue partition or not. This is disadvantageous when there are more instances of the application than available partitions of the queue, in this case some instances of the application will be left without a queue partition to consume from. Further, it also relies on the fact that there are no other applications consuming from the same queue partitions (i.e. applications that are not instances of the same distributed application). 
       SUMMARY OF THE INVENTION  
       [0032]    According to a first aspect, there is provided a method for an application instance to request attachment to a queue partition on a messaging server within a plurality of messaging servers, each messaging server holding at least one queue partition, the set of queue partitions together forming a single queue, the method comprising: an application instance requesting attachment to a queue partition, the request requesting exclusivity with regard to other application instances having a common identifier; and responsive to an indication that the request has been successful, interacting with the queue partition. 
         [0033]    In one embodiment, there are a plurality of applications comprising at least two instances each. In this case the common identifier is an application id and the request requests that the requesting application instance is the only instance of the application attached to the queue partition. 
         [0034]    In one embodiment, the common identifier is a message type and the request requests that the requesting application instance is the only application instance consuming a particular message type when compared with other application instances already attached to the queue. Message type could be based on a selector (filter) provided by the application instance at attach time or could be based on a message property provided at attach time. 
         [0035]    In one embodiment, exclusivity is only requested while the attach request is being processed by a receiving messaging server. If the request is unsuccessful, then the same request is preferably made of each queue partition within the set, until either attachment is successful, or all queue partitions have received yet been unable to fulfil the request. If all queue partitions are unable to fulfil the request, attachment to a queue partition is preferably requested without regard for other application instances. The queue partition is then attached to the application instance. 
         [0036]    In one embodiment, with each receipt of an indication that an attachment request has been unsuccessful, the number of application instances that prevented the attachment request from being successful are received. Such information is used to determine which of the queue partitions in the set potentially has the least number of preventing application instances attached thereto. Attachment to the queue partition with potentially the least number of preventing application instances attached thereto is then preferably requested. 
         [0037]    According to another aspect, there is provided a method for a messaging server to process an attachment request from an application instance requesting attachment to a queue partition on the messaging server, the messaging server being one within a plurality of messaging servers, each messaging server holding at least one queue partition, the set of queue partitions together forming a single queue, the method comprising: receiving an attachment request from an application instance requesting attachment to a queue partition, the request requesting exclusivity with regard to other application instances having a common identifier; determining whether the request can be fulfilled; and responsive to a negative determination, rejecting the attachment request. 
         [0038]    The invention may be implemented in computer software and distributed via storage media, which can include by carrier transmission. 
     
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0039]    First and second embodiments of the present invention will now be described, by way of example only, and with reference to the following drawings: 
           [0040]      FIG. 1  illustrates the environment in which a first embodiment of the invention operates; 
           [0041]      FIGS. 2   a  and  2   b  show the components of a consuming application and a messaging server, in accordance with the first embodiment; 
           [0042]      FIGS. 3   a  and  3   b  show the processing performed by a consuming application and a messaging server, in accordance with the first embodiment; 
           [0043]      FIG. 4   a  illustrates the environment in which a second embodiment of the invention operates; and 
           [0044]      FIGS. 4   b  and  4   c  show the processing performed by a consuming application and a messaging server, in accordance with the second embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0045]      FIG. 3  illustrates the environment in which the present invention, in accordance with a first embodiment, operates. In this first embodiment there are multiple applications (or indeed multiple instances of a single application) that ail consume the same type of messages and that are responsible for all messages on queue partitions  40 ,  50 ,  60 . 
         [0046]    Producer applications  70 ,  80 ,  90  transmit messages to messaging servers  10 ,  20 ,  30  where they are placed on one of queue partitions  40 ,  50 ,  60  for retrieval by consuming applications  95 . As discussed previously, it is important to ensure that the consuming applications are evenly distributed across queue partitions. Otherwise it is possible that messages may be left marooned on a queue partition without any application for consuming them. Equally however, if there are more consuming applications than partitions, it is important not to waste any of the consuming applications. 
         [0047]      FIGS. 2   a  and  2   b  illustrate the components of a first embodiment of the present invention.  FIGS. 3   a  and  3   b  show the processing performed by such components in accordance with the first embodiment. These figures should be read in conjunction with one another. 
         [0048]    Consuming application  95  requests (via attach requester  100 ) an exclusive attach to queue partition  40  (step  200 ). This means that application  95  wants (at the time of attach) to be the only application attached to the queue partition. Messaging server  40  receives the attach request at step  300  via attach request receiver  130 . At step  310 , determiner component  140  determines whether exclusive access is being requested. If the answer is no, then attacher  150  permits the attach to go ahead (step  320 ) and informer component  170  informs the consuming application that the attach has been successful (step  330 ). 
         [0049]    The consuming application  95  receives notification of the success of the attach via success/failure component  110  (step  210 ) and begins to consume messages from the queue partition to which it has attached via consumer component  125 . 
         [0050]    If, on the other hand, an exclusive attach is requested, then the determiner component  140  at messaging server  10  determines whether other consumers are already attached (step  340 ). If the answer is no, then attacher  150  permits the attach to go ahead and informer component  170  informs the consuming application that the attach has been successful. 
         [0051]    Again, consuming application  95  receives notification of the success of the attach via success/failure component  110  (step  210 ) and begins to consume messages from the queue partition local to which it has attached via consumer component  125 . 
         [0052]    If it is determined at step  340  by messaging server  10 &#39;s determiner component  140  that there are other consumers already attached, the attach request is rejected by failure component  160  (step  350 ). Informer component  170  then informs the consuming application that their attach has not been successful (step  360 ). 
         [0053]    The consuming application  95  uses success/failure receiver  110  to determine at step  210  that the attach has failed. 
         [0054]    The consuming application then attempts to select another queue partition for which an exclusive attach can be requested instead (step  230 , selector  105 ). Each consuming application has access to (either locally or shared access) a list of available queue partitions. This may be requested at startup. Selector  105  works its way through this list. 
         [0055]    If another queue partition can be selected (step  230 ), then the process loops round. If, on the other hand, all queue partitions already have consuming applications attached, then the consuming application may choose to attach to a queue partition (step  240 , attach requester  100 ) that is already associated with one or more consuming applications audio start consuming therefrom (step  220 , consumer  125 ). In other words, the consuming application does not specify the “exclusive” attach option second time around (normal attach only). It does not matter if other applications, already attached to the queue partition, are attached with the exclusive option set. This is because the exclusivity was only enabled while the attach request was processed. 
         [0056]    With respect to deciding which queue partition to target second time around, this may be the queue partition with the least number of consuming applications currently attached. Each time an attach failure is received by component  110  at step  210 , this component also receives an indication from the relevant messaging server (via an informer component  170 ) as to the number of consuming applications currently attached to the queue partition. The consuming application uses this information to keep track of the queue partition with the least number of consuming applications attached and then preferably requests anon-exclusive attachment to that queue partition. Of course, such information is not guaranteed to be entirely accurate since consuming applications can attach and detach. However, it gives the requesting consuming application an idea, as to which queue partition might be the most sensible one to attach to. A consuming application may choose to periodically poll other messaging servers to find out how many consuming applications are attached to their queue partitions to be able to make a determination as to whether it is appropriate to relinquish a current attachment in favour of another one. 
         [0057]    It is important to note that, unlike the prior art, the exclusive attach option is relevant at attach time only. This means that consuming applications  95  are not prevented from requesting access to a queue partition when, another consuming application  95  had previously requested an exclusive attach to that queue partition and is still attached thereto. 
         [0058]    Thus when there are more consuming applications  95  than queue partitions, consuming applications may double up (treble up etc.) on a queue partition. In this way, consuming application resources are not wasted. A prior art exclusive attach meant that only one consuming application  95  at a time could attach to a queue partition. This was because the exclusivity lasted for the duration of the attach rather than be relevant at attach time only. Preferably the number of consuming applications  95  already attached to the various queue partitions is taken into account. 
         [0059]    A second embodiment will now be discussed with reference to  FIGS. 4   a  and  4   b.    FIG. 4   a  illustrates the environment in which the second embodiment is relevant and  FIGS. 4   b  and  4   c  show the processing performed by the messaging server. Note, the actual components to achieve such processing is not illustrated since this is very similar to the components provided for the first embodiment, 
         [0060]    As shown in  FIG. 4   a,  it is possible for different applications (e.g. X and Y) to be consuming from a set of messaging servers. Each application may consume a different type of messages and may do so via a plurality of application, instances. For example, application X may have four application instances, while application Y may only have 2 application instances. The danger is that if a round robin distribution is used to allocate application instances to messaging servers  10 ,  20 ,  30 , one may end up with ail of an application&#39;s instances consuming from only a subset of the available messaging servers. For example, application X instances 1 and 3 may consume from a queue partition on messaging server  10 , while application X instances 3 and 4 may consume from a queue partition on messaging server  20 . Thus it can be seen that messaging server  30  does not have anything to do with application X. This is problematic if applications X and Y consume different types of messages. Messages meant for application X on messaging server  30  will be left unconsumed. 
         [0061]    Note, application instances may consume a type of message based on some property of the messages or may use a filter (selector) to select messages based on the value of header or payload content. 
         [0062]      FIGS. 4   b  and  4   c  show how this problem is addressed and should be read in conjunction with one another. Each application has an id associated therewith. When an application instance (e.g. X, instance 1) requests an exclusive attach to queue partition, the request includes the id of the requesting application (e.g. X). Application X may therefore request that only one instance of itself be allowed to attach to the queue partition via an “exclusive within id set” attach option (step  500 ). An application&#39;s instances are typically completely separate. Thus one instance of an application is not aware what other instances of the same application have done previously. 
         [0063]    Messaging server  40  receives the attach request at step  400  and determines at step  410  whether the request pertains to an “exclusive within id set” request. If the answer is no, then the consumer is attached and informed of the attach success (steps  420 ,  430 ). That is unless there is also a test as to whether the request is of the exclusive sort discussed with reference to  FIG. 3   b,  step  310 . 
         [0064]    The consuming application X receives notification of the success of the attach at step  510  and begins to consume messages from the queue partition local to the messaging server ( 520 ). 
         [0065]    If it is determined at step  410  that application X desires to attach only if no other instances of itself are already attached, then a determination at step  440  as to whether other instances of the same application are already attached. This is achieved by determining the ids of those applications already attached to see whether there is a match between any of those and the id included with the current request. If the answer is no, then application is attached and is informed of the success of the attach (steps  420 ,  430 ). 
         [0066]    Again, the consuming application X receives notification of the success of the attach at step  510  and begins to consume messages from the queue partition to which it is attached ( 520 ). 
         [0067]    If on the other hand, other instances of the same application are already attached to the queue partition, then the attach request is rejected (step  450 ). The application is informed of the failure at step  460 . 
         [0068]    Failure is determined by application X at step  510  and it is then determined whether it is possible to select another queue partition (step  530 ). As with the first embodiment, the consuming application works its way through a list of available queue partitions obtained, for example, at startup. 
         [0069]    If there is another queue partition, then the process loops round and application X attempts to attach to another queue partition. If on the other hand, the list of queue partitions has been exhausted, it is preferably permitted for application X to attach to a queue partition at which other instances of itself already exist (step  540 ). In this way, the resource of application X is not wasted. 
         [0070]    Similar to that described with reference to the first embodiment, when an attach request fails the consuming application is preferably informed as to the number of instances of itself already attached to that queue partition. The application instance preferably remembers which queue partition has the fewest instances of itself attached and requests attachment to this queue partition. The id of the requesting application is still included with the request. This is so that future consumers can be given an accurate count of attached consumers with this id. The application instance may choose to poll the other messaging servers periodically to determine whether its information is current. 
         [0071]    While the second embodiment has been described in terms of an application instance requesting exclusive access to a queue partition with regard to application instances having the same id, the invention is not limited to such. Exclusive access could equally be requested with regard to application instances consuming the same type of message. Examples are application instances using the exact same selector or filter (e.g. only one application instance will consume IBM stock information from a particular queue partition) or application instances consuming based on the same property of a message. An application instance will specify its selector or property at attach time. Effectively the selector/property specified becomes the id (referred to earlier) of the consuming application instance. 
         [0072]    Such exclusivity does not have to be at attach time only but could be for the duration of the attach. This does however mean that an application&#39;s instances may not double up etc. Note, each application may comprise one or more application instances. 
         [0073]    It will be appreciated that while the invention has been described in terms of consuming applications only, the invention is equally applicable to producing applications. 
         [0074]    While the invention has been described in terms of queue partitions, it is possible for multiple queues to form a larger logical queue. Thus the term ‘partitioned queue’ is intended to encompass this, as is the term, ‘queue partition’. 
         [0075]    Further, a messaging server may contain more than one queue partition. Those queue partitions may belong to the same logical queue or different queues. 
         [0076]    It should be appreciated that a system may be provided that can cope with applications requesting exclusivity within an id set, using a selector or according to the first embodiment.