Allocating space in message queue for heterogeneous messages

#The present invention relates to computing environments, and deals more particularly with allocating space for storing heterogeneous messages in a message queue according to message classification such as message type.

#Currently-known messaging engines determine the total number of messages which can be stored based on a specified “queue depth” parameter value. This queue depth value is typically a static value that counts the number of stored messages, and messaging engines using this approach ensure that the number of stored messages does not exceed the queue depth value. In another known approach, the static value specifies the maximum amount of space the queued messages can occupy. In one known alternative, instead of using a static value, the queue depth value is dynamically modifiable using scripts or triggers. For example, executable code may be invoked from a script, or responsive to an event, to change the queue depth value at run time.

#The present invention is directed to queuing messages in allocated space of a message queue in a computing system. In one aspect, this comprises: determining a classification of a message to be queued in the message queue; determining an amount of the space allocated to queuing messages having the determined classification; determining an amount of the space in use for already-queued messages having the determined classification; and if the determined amount of the space in use does not exceed the determined amount of the space allocated, then queuing the message in the message queue and updating the amount of the space in use, and otherwise, sending the message for queuing temporarily in a secondary queue.

#The present invention will be described with reference to the following drawings, in which like reference numbers denote the same element throughout.

#FIG. 1 depicts a sample data structure which defines message classifications for messages that may be held in a message queue;

#FIGS. 2-8 provide flowcharts depicting logic which may be used when implementing an embodiment of the present invention;

#An embodiment of the present invention allocates space for heterogeneous messages to be stored in a message queue, based on classifying the messages. By way of illustration but not of limitation, examples presented herein are primarily directed to scenarios where the classification is based on a message type. Notably, the message type is not required to be in a specific “message type” field. Instead, the message type may be determined from any part of the message data or a specific message selector string or any property in the message. As one alternative to classifying messages by message type, the messages may be classified according to the application which sent the message for queuing. As another alternative, messages may be classified according to the network type over which those messages are sent to the messaging engine for queuing or, similarly, the network protocol with which the messages are delivered to the messaging engine. As still another alternative, messages may be classified according to the target recipient (which may be expressed as a particular user, or as a particular application, and so forth). In the general case, information used in the classification of a message may be specified in the message explicitly, or it may be determined from characteristics of the message—for example, by programmatically inspecting one or more strings and/or properties of the message.

#Disadvantages of using known techniques that set a queue depth to a fixed number of messages or to a fixed amount of storage space will now be discussed.

#Suppose a messaging engine uses a fixed queue depth value of 10,000 messages. Some applications may send relatively short messages for queuing, while other applications send relatively long messages. Simply counting the total number of messages may lead to less-than-optimal queuing. For example, if one application sends messages which are 50 Megabytes in length, and for some reason messages are not being dequeued quickly enough, the system may run out of storage space even before the queue depth limit is reached.