deployment request messages are going to the DLQ

I am opening this as a support ticket so we can resolve the stuck messages if Optus hasn't already sent redeployments for the affected accounts. We'll also have to monitor this.

This is high priority because it means clients that signed up for our system might not have had Google accounts or sites generated. It depends on the original destination of the message, and whether optus sent a redpeloyment for that account or not. It's possible most of these were resolved if we ever ran an upgrade script that triggered site generation deployments or ADS deployments.

This query shows the message headers, which include the original detination queue. Many are request queues. There are a few which are response queues, which means the optus system doesn't know the deployments succeeded.

select HEADERS from JBM_MSG join JBM_MSG_REF on (JBM_MSG_REF.MESSAGE_ID = JBM_MSG.MESSAGE_ID) order by timestamp desc\G

Note: me

This shows all messages that weren't consumed. CHANNEL_ID=0 is the DLQ.

mysql> select * from JBM_POSTOFFICE where CHANNEL_ID=0\G

• • • • • • • • • • • • • • • • • • • • • • • • • • • 1. row ***************************
                                                      POSTOFFICE_NAME: JMS post office
                                                      NODE_ID: 1
                                                      QUEUE_NAME: DLQ
                                                      COND: queue.DLQ
                                                      SELECTOR: NULL
                                                      CHANNEL_ID: 0
                                                      CLUSTERED: N
                                                      ALL_NODES: N
                                                      1 row in set (0.00 sec)

select JBM_MSG.MESSAGE_ID, RELIABLE, EXPIRATION, PRIORITY, from_unixtime(floor(TIMESTAMP/1000)) 'ts', TYPE, CHANNEL_ID, DELIVERY_COUNT, ORD, PAGE_ORD, STATE from JBM_MSG join JBM_MSG_REF on (JBM_MSG_REF.MESSAGE_ID = JBM_MSG.MESSAGE_ID) order by timestamp desc;
--------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------
68 rows in set (0.01 sec)