Siva's Blog

In this post, we will see how Durable Subscribers work when using AQJMS. It’s advised to have a look at previous post to understand on how to switch to AQJMS from default Weblogic JMS.

We will use the following Business Events for demonstration purpose where CreateOrder event has 3 subscriptions and UpdateOrder has 1 subscription and Durable property is set to Yes.

From JMS Mapping shown below, you can find out the JNDI of JMS topic which is jms/fabric/EDNAQjmsTopic.

In WLS Admin Console, navigate to Services –> Messaging –> JMS Modules –> SOAJMSModule –> EDNAQjmsForeignServer –> Destinations and observe Remote JNDI of corresponding JNDI of JMS topic observed in above step. From this, actual AQ topic used by EDN is EDN_AQJMS_TOPIC.

You can observe AQ Topic and corresponding DB table used by EDN to store messages as shown below. Remember to connect to DB using SOAINFRA schema credentials.

In addition to queue table, following are other DB tables used by EDN and will be created automatically as part of SOAINRA schema creation or when you create any custom AQ topic.

Following information is an extract from this documentation and presenting for your quick reference here.

Table name	Description
AQ$_queue_table_name_D	Table for storing information about propagations and apply processes that are eligible for processing each event.
AQ$_queue_table_name_E	Default exception queue associated with the queue table.
AQ$_queue_table_name_H	An index organized table (IOT) for storing dequeue history data.
AQ$_queue_table_name_I	An index-organized table (IOT) in the case of multiple consumer queues for dequeue operations.
AQ$_queue_table_name_L	Dequeue log table, used for storing message identifiers of committed dequeue operations on the queue.
AQ$_queue_table_name_P	Table for storing the captured events that spill from memory.
AQ$_queue_table_name_S	A table for storing information about subscribers.
AQ$_queue_table_name_T	An index for the queue monitor operations

We will discuss about the important tables below from this list.

AQ$_EDN_AQJMS_TOPIC_TABLE_S

You can query this table to find the Durable subscribers as shown below.

You can also get information about these subscribers in following way.

Click on Subscribers. You can observe Consumer Name, Delivery Mode and whether it’s Durable subscriber or not.

EDN_AQJMS_TOPIC_TABLE

This is queue table associated with our AQ and you can observe the messages in this table when you raise a business event. You can also get MSGID from EDN log (refer to this post on how to generate EDN logs).

Following screenshot shows the message created when CreateOrder event is raised.

You can also see event payload  in USER_DATA column as shown below.

AQ$_EDN_AQJMS_TOPIC_TABLE_H

This table contains de-queue history for each of subscribers of an event. The following screenshot shows messages for 3 subscribers of CreateOrder event (observe subscriber# column below).

AQ$_EDN_AQJMS_TOPIC_TABLE_I

This table contains messages meant for de-queue operations for each of subscribers of an event. This we can observe clearly when any of the durable subscribers are down, which we will see later.

It has been observed that the messages are being purged automatically from the above tables, once all subscribers have received the event and successfully processed it.

If the business events are staged in buffer for a period of time without being de-queued, or if there is no enough space in memory to hold all of these captured events, then the tables AQ$_EDN_AQJMS_TOPIC_TABLE_P and AQ$_EDN_AQJMS_TOPIC_TABLE_D are used to store these spilled events.

Now we will observe how these subscribers get affected in the following scenarios:

• Deployment of composites with Durable property to Yes.
• Any of the Composites subscribed to business events are shutdown.
• Redeployment of composites with same revision.
• Redeployment of composites with different default revision. 
• Un-deployment of the composites.
• Redeployment of composites after modifying Durable property to No.

Durable property to Yes:

We have already seen above that subscribers have been created as expected where Subscriber/Consumer name has corresponding Business Event name.

Subscribers Down:

Shutdown one of the composites subscribing to CreateOrder business event. In this case you can observe the records in all of the above tables that we discussed as all subscribers have not processed the event.

EDN_AQJMS_TOPIC_TABLE

AQ$_EDN_AQJMS_TOPIC_TABLE_I

This table shows only one message corresponding to inactive subscriber.

AQ$_EDN_AQJMS_TOPIC_TABLE_H

This table clearly shows that 2 of the messages related to active subscribers have been de-queued along with de-queue time and one more message is yet to be de=queued as the subscriber is down.

AQ$_EDN_AQJMS_TOPIC_TABLE_F

This table also shows only one message corresponding to inactive subscriber along with other information present in EDN_AQJMS_TOPIC_TABLE.

Now bring up the composite and query all of the above tables and you will find them empty as the message is delivered as expected.

Redeployment of Composites:

Redeployment of some composites with same revision resulted into recreation of Durable Subscribers and older ones are either completely deleted or just updated with Deletion Time but Subscriber/ Consumer name is never changed as shown below. Also Subscriber Type is set to 2 denoting UNDELIVERABLE.

Same is the case when composites are redeployed with different revision but now Subscriber/Consumer name is also modified as shown below.

Un-deployment of Composites:

Un-deployment of composites also resulted into either deletion of entries or Deletion Time and Subscriber Type is updated as described in previous scenario. But could not conclude on why 2 different behaviors exist.

Durable property to No:

Subscribers have been created as expected but Subscriber/Consumer name are set differently as shown below.

Let us bring down the composite down once again to see how it’s affected the subscriber. From the below screenshot, you can observe that corresponding subscribers are marked with Deletion time and Subscriber type is set to 2 means undeliverable.

Other Observations:

• Subscriber Type is 193 in table aq$_edn_aqjms_topic_table_S when subscriber is active and value 2 denotes undeliverable.
• The message assumes the following states during it’s lifecycle and the column state in table edn_aqjms_topic_table denotes this. These value are derived from definition of DB view AQ$EDN_AQJMS_TOPIC_TABLE.

State	Meaning
0	Ready
1	Wait
2	Processed
3	Expired
8	Deferred
10	Buffered Expired

• When any one of the composites throws an exception (considering the BPEL invocation is Sync), retry is happening thrice as expected and retry count is marked in aq$_edn_aqjms_topic_table_H as shown below.

       

       

Note: Could not conclude the purpose of tables AQ$_EDN_AQJMS_TOPIC_TABLE_F and AQ$_EDN_AQJMS_TOPIC_TABLE_G and AQ$_EDN_AQJMS_TOPIC_TABLE_T . If anybody is aware of the functionality, one can let me know through your comments. And the table AQ$_EDN_AQJMS_TOPIC_TABLE_L showing log only during events delivery and is getting cleared once all events have been processed successfully.