System, method, and computer program for fetching data from a physical memory queue utilizing an alias queue name

A system, method, and computer program product are provided for fetching data from a physical memory queue utilizing an alias queue name. In use, a physical queue associated with at least a portion of memory is identified. Additionally, a first alias queue name is mapped to the physical queue. Further, data is fetched utilizing the first alias queue name in response to a request to fetch the data from the physical queue.

FIELD OF THE INVENTION

The present invention relates to accessing data from physical queues utilizing logical queue names.

BACKGROUND

There is generally an outage or interruption in service when switching between applications listening, getting, and servicing requests from a particular memory queue. The activation/deactivation process of an application set usually takes a few minutes, thus creating an outage. The activation/deactivation process of an application set is also error prone since it is handled at the client level.

SUMMARY

A system, method, and computer program product are provided for fetching data from a physical memory queue utilizing an alias queue name. In use, a physical queue associated with at least a portion of memory is identified. Additionally, a first alias queue name is mapped to the physical queue. Further, data is fetched utilizing the first alias queue name in response to a request to fetch the data from the physical queue.

DETAILED DESCRIPTION

FIG. 1illustrates a method100for fetching data from a physical memory queue utilizing an alias queue name, in accordance with one embodiment.

As shown, a physical queue associated with at least a portion of memory is identified. See operation102. The physical queue may include any portion or portions of the memory. Moreover, the memory may include any type of memory. In one embodiment, identifying the physical queue may include allocating a portion or portions of the memory to the physical queue.

Additionally, a first alias queue name is mapped to the physical queue. See operation104. The first alias queue name may include any logical name and may include any number of characters, symbols, and/or numbers, etc.

Further, data is fetched utilizing the first alias queue name in response to a request to fetch the data from the physical queue. See operation106. The data may include any data stored in the physical queue. The data may be fetched utilizing a GET operation (e.g. MQGET, etc.).

The first alias queue may be associated with various applications and/or application programming interfaces (APIs). For example, the first alias queue name may be associated with a primary application programming interface.

In one embodiment, the method100may further include receiving an indication to utilize a maintenance application programming interface instead of the primary application programming interface. In this case, the maintenance application programming interface may have the same functionality as the primary application programming interface.

Additionally, a second alias queue name may be mapped to the physical queue. The second alias queue name may be associated with the maintenance application programming interface. Moreover, the second alias queue may be different than the first alias queue name.

When it is desired to use the maintenance application programming interface, as opposed to the primary application programming interface (e.g. in response to performing maintenance on the primary API, etc.), the maintenance application programming interface may be utilized without any down time. For example, the first alias queue name may be mapped to a dummy queue and additional data may be fetched utilizing the second alias queue name in response to a request to fetch the additional data from the physical queue. The additional data may be fetched utilizing the second alias queue name without any disruption of service to application usage associated with the APIs.

As another example of a use case, such techniques may be used in the context of usage scaling. For example, the first alias queue name may be associated with a first set of applications.

Further, a plurality of different alias queue names may be mapped to the physical queue. In this case, each of the different alias queue names may associated with a different set of applications (e.g. application set A, application set B, etc.).

Thus, if it is determined to scale up usage associated with the first set of applications (e.g. during a peak usage time, etc.), it may be determined to scale up usage associated with the first set of applications by utilizing the different set of applications. Accordingly, data may be fetched from the physical queue utilizing the plurality of different alias queue names, such that the different set of applications are capable of being utilized without interruption to use of first set of applications (e.g. without any outage, etc.).

Client applications that connect to a message queue may use different alias queues to connect. These may be activated by targeting the alias queue to the real queue, or may be deactivated by targeting the alias queue to a dummy queue, as and when required. The connections shift when custom message queue channels are refreshed and it takes fraction of a second for the connections to shift.

Thus, the method100may be implemented such that application clients fetch messages not from the real physical queue but from an alias name mapped to the real queue. Additionally, the method100may be utilized to implement a production application maintenance strategy to achieve high availability for applications servicing messages from a queue. This strategy works by switching application sets listening to a particular queue and servicing requests, to a different set of applications with minimal or no outage.

There is generally an outage if a system switches between applications listening, getting, and servicing requests from a particular queue. The activation/deactivation process of an application set usually takes a few minutes, thus creating an outage. This process is also error prone since it is handled at the client level. Utilizing the method100, dependencies at a client level are completely removed and it is a single channel bounce that triggers the switch. This process ensures that switching between two sets of applications is seamless.

The method100may function to implement an effective strategy where aliases, which are logical names, are mapped to actual queues.

FIG. 2illustrates a system flow200for fetching data from a physical memory queue utilizing an alias queue name, in accordance with one embodiment. As an option, the system flow200may be implemented in the context of the details ofFIG. 1. Of course, however, the system flow200may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

As shown in scenario A, a primary application programming interface (API)202is UP with MDB (message driven bean). The primary API202is listening to primary alias queues204. The primary alias queues204are aliases pointing to real queues.

In this example, a maintenance API206is brought up with MDB listening to a maintenance alias queue208, which is pointing to dummy queues210.

As shown in scenario B, the aliases are switched, verified and a SVRCONN channel is restarted to refresh connections at QMGR, where nothing changes at the WL. Additionally, the maintenance API206is activated.

The primary API202and the maintenance API206are identical application sets and each set connects to a different alias queue to get messages. The aliases are swapped from a dummy queue to a real queue as a target to fetch (GET) messages. The switch is seamless using the techniques described.

FIG. 3illustrates system flow examples300for fast on-demand switching, in accordance with one embodiment. As an option, the system flow examples300may be implemented in the context of the details of the previous Figures. Of course, however, the system flow examples300may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

Fast on-demand switching of application sets servicing a particular kind of request may be performed based on the incoming request volume. Scaling and de-scaling of an application can be done in a fraction of a second, bringing in virtues of flexibility, optimized usage of resources, and reduced cost of operation.

With reference toFIG. 3, and as an example implementation, there may be APIs that are listening to actual physical queues servicing “Add” and “Multiply” API service calls.

As shown in example A, APP 1 is currently servicing an “Add API Operation Queue” requests through logical queue “APP1 Alias Q”. APP 2 is also servicing “Add API Operation Queue” requests through logical queue “APP2 Alias Q”. Further, APP 3 is servicing “Multiply API Queue” requests through logical queue “APP3 Alias Q”.

During the peak hours, “Multiply Operation API Queue” may be getting more requests and “Add Operation API Queue” may not be getting many requests. Thus, it may be decided to adjust to the requirement with the same resources with the options that the techniques described herein provide.

Thus, as shown in example B, the alias/logical name may be switched from where the “APP 1” is fetching messages and mapped to “Multiply Operation Queue”. This takes effect by refreshing connection channels within a fraction of a second.

Accordingly, lesser application resources may be flexibly managed to adjust to fluctuating demand, or even schedule requests in batches to optimize hardware/software usage.

FIG. 4illustrates a network architecture400, in accordance with one possible embodiment. As shown, at least one network402is provided. In the context of the present network architecture400, the network402may take any form including, but not limited to a telecommunications network, a local area network (LAN), a wireless network, a wide area network (WAN) such as the Internet, peer-to-peer network, cable network, etc. While only one network is shown, it should be understood that two or more similar or different networks402may be provided.

Coupled to the network402is a plurality of devices. For example, a server computer404and an end user computer406may be coupled to the network402for communication purposes. Such end user computer406may include a desktop computer, tap-top computer, and/or any other type of logic. Still yet, various other devices may be coupled to the network402including a personal digital assistant (PDA) device408, a mobile phone device410, a television412, etc.

FIG. 5illustrates an exemplary system500, in accordance with one embodiment. As an option, the system500may be implemented in the context of any of the devices of the network architecture400ofFIG. 4. Of course, the system500may be implemented in any desired environment.

As shown, a system500is provided including at least one central processor501which is connected to a communication bus502. The system500also includes main memory504[e.g. random access memory (RAM), etc.]. The system500also includes a graphics processor506and a display508.

The system500may also include a secondary storage510. The secondary storage510includes, for example, a hard disk drive and/or a removable storage drive, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, etc. The removable storage drive reads from and/or writes to a removable storage unit in a well known manner.

Computer programs, or computer control logic algorithms, may be stored in the main memory504, the secondary storage510, and/or any other memory, for that matter. Such computer programs, when executed, enable the system500to perform various functions (as set forth above, for example). Memory504, storage510and/or any other storage are possible examples of tangible computer-readable media.