PEInternalTopic DeadLetter queue fills

, , ,
1

Dear All,

I was wondering if someone could enlighten me on some issue we have on our Integration Server & Broker.

We have in our environment :
Integration Server 7.1.2
Broker of same Suite
Oracle Database 11gR2
MQ connections as well as JMS.

Also we have setup JMS Consumer Trigger as below :

Connection Alias Name : PE_NONTRANSACTIONAL_ALIAS
Transaction Type : NO_TRANSACTION
Connection Client ID : JMSConsumer
Create Connection Using : NATIVE WEBMETHODS API
Client Group : IS-JMS
Class Loader : INTEGRATION_SERVER
Maximum CSQ Size : UNLIMITED
Drain CSQ In Order : Yes

Upon enabling a new customer (using JDBC Adapter and JMS Listeners, we notice that the Broker Dead Letter Queue get populated by many documents all with same name and same size:

“PEInternalTopic” size=1000 AckStatus=Available
RedeliveryCount: -1

If I look inside that document I see following :

PEInternalTopic {     byte bytes[] = {          11, 4, 0, 0, 0, 1, 5, 1, 4, 25, 0, 99, 0, 111, 0, 109, 0, 46, 0, 119, 0, 109, 0, 46, 0, 100, 0, 97, 0, 116, 0, 97, 0, 46, 0, 73, 0, 83, 0, 77, 0, 101, 0, 109, 0, 68, 0, 97, 0, 116, 0, 97, 0, 73, 0, 109, 0, 112, 0, 108, 4, 27, 0, 119, 0, 109, 0, 46, 0, 112, 0, 114, 0, 116, 0, 46, 0, 115, 0, 116, 0, 97, 0, 116, 0, 117, 0, 115, 0, 58, 0, 67, 0, 104, 0, 97, 0, 110, 0, 103, 0, 101, 0, 67, 0, 111, 0, 109, 0, 109, 0, 97, 0, 110, 0, 100, 5, 1, 0, 2, 4, 17, 0, 80, 0, 114, 0, 111, 0, 99, 0, 101, 0, 115, 0, 115, 0, 73, 0, 110, 0, 115, 0, 116, 0, 97, 0, 110, 0, 99, 0, 101, 0, 73, 0, 68, 4, 32, 0, 101, 0, 56, 0, 101, 0, 50, 0, 100, 0, 54, 0, 54, 0, 48, 0, 97, 0, 56, 0, 49, 0, 51, 0, 49, 0, 49, 0, 101, 0, 48, 0, 56, 0, 101, 0, 51, 0, 100, 0, 57, 0, 98, 0, 97, 0, 100, 0, 52, 0, 49, 0, 99, 0, 56, 0, 53, 0, 57, 0, 56, 0, 53, 4, 14, 0, 80, 0, 114, 0, 111, 0, 99, 0, 101, 0, 115, 0, 115, 0, 77, 0, 111, 0, 100, 0, 101, 0, 108, 0, 73, 0, 68, 4, 43, 0, 101, 0, 117, 0, 68, 0, 99, 0, 103, 0, 70, 0, 114, 0, 97, 0, 109, 0, 101, 0, 119, 0, 111, 0, 114, 0, 107, 0, 47, 0, 101, 0, 117, 0, 68, 0, 99, 0, 103, 0, 70, 0, 114, 0, 97, 0, 109, 0, 101, 0, 119, 0, 111, 0, 114, 0, 107, 0, 47, 0, 77, 0, 97, 0, 110, 0, 105, 0, 102, 0, 101, 0, 115, 0, 116, 0, 105, 0, 110, 0, 103, 0, 69, 0, 120, 4, 19, 0, 80, 0, 114, 0, 111, 0, 99, 0, 101, 0, 115, 0, 115, 0, 77, 0, 111, 0, 100, 0, 101, 0, 108, 0, 86, 0, 101, 0, 114, 0, 115, 0, 105, 0, 111, 0, 110, 4, 1, 0, 49, 4, 16, 0, 80, 0, 114, 0, 111, 0, 99, 0, 101, 0, 115, 0, 115, 0, 73, 0, 116, 0, 101, 0, 114, 0, 97, 0, 116, 0, 105, 0, 111, 0, 110, 0, 11, 4, 6, 0, 65, 0, 99, 0, 116, 0, 105, 0, 111, 0, 110, 4, 4, 0, 70, 0, 65, 0, 73, 0, 76, 2, 0, 2, 0     };     struct {         unicode_string $coderType;         unicode_string type;     } Properties = {         $coderType = "idata_bytes";         type = "Status";     };         struct {         unicode_string jms_destination;         unicode_string jms_messageID;         long jms_timestamp;         int age;         int flags;         date enqueueTime;         date recvTime;         unicode_string pubId;         int storageType;     } _env = {         jms_destination = "jmstopic:/PEInternalTopic";         jms_messageID = "ID:11756217-31-6-1862";         jms_timestamp = 1309986428756L;         age = 1618724;         flags = 16;         enqueueTime = "07/06/2011 23:07:08.758";         recvTime = "07/06/2011 23:07:08.758";         pubId = "JMSConsumer";         storageType = 1;     }; };

Basically I would like to know what are those and how to avoid filling the deadletter. From a technical and business point of view the new project is working fine with all documents processed and delivered as expected… Just those documents are there filling up constantly…

Please any light?

Thanks

Jeremy

2

We found the cause of this issue.
In a clustered environment, the ID of the JMS topic to the broker must be unique otherwise it clashes in the broker.

So solution was to add _1 to the ID of the 1st integration server of the cluster and _2 to the ID of the second integration server JMS topic (Messaging/JMS Settings)