SOA 10g JMS adapter does not pick up large messages in Oracle AQ

Question

I am using SOA 10g 10.1.3.4 MLR #9. When I enqueue a large JMS message ( of type SYS.AQ$_JMS_TEXT_MESSAGE ) into the AQ from SOA 11g it goes into the TEXT_LOB portion of the USER_DATA column in AQ. In addition to this GROUPID and GROUPSEQ do not seem to get set. When that happens, my JMS adapterfrom SOA 10g does not seem to dequeue the message. But if I enqueue the same message using sql and set the GROUPID and GROUPSEQ my JMS adapter from 10g picks up the clob message.
How do we make the 10g adapter always pick up the large message in TEXT_LOB? I don't have this problem when the message is small because it goes into TEXT_VC field instead of TEXT_LOB field.

Answer 1

We are having this problem and have not figured it out yet. We need help. An oracle SR is opened but no progress from Oracle yet. I need to get some traction on this so anyone's help is appreciated. Our suspicion is that the AQ client in the wls 10.3.1 is incorrectly choosing to put the xml payload in TEXT_LOB even though the character size is less than 4000.
Here is a summary of our observations....
Today we did some testing with our old 6.3.1 OSM environment and our new 7.0.2 environment. We tested each against our QA1 environment and then our QA2 environment. Scenrio 1 is our problem. Scenario 2,3,and 4 all behave similar to each other. Why does Scenario 1 behave differently. It is causing AIA a problem when it dequeues the message.
Scenario 1:
We pointed our 7.0.2 OSM/Weblogic 10.3.1/Out of the Box AQ (which is part of our QA1 environment) to send messages to the AIA AQ table in our QA1 environment. The AIA database uses ALT32UTF8 character set. We don't know what character set the 7.0.2 OSM/Weblogic/AQ uses. Wehn we sent messages to the AIA QA1 table we saw that everything under TEXT_LEN 1000 went to TEXT_VC, Over 1000 went to TEXT_LOB. This is causes AIA to throw an exception if the message is over 1000 when it dequeus the message, because it thinks it shoudl look in the TEXT_VC which is null for AIA.
Scenario 2:
We pointed our 7.0.2 OSM/Weblogic 10.3.1/Out of the box AQ (which is part of our QA1 environment) to send messages to the AIA AQ table in our QA2 enviornment. The AIA database uses UTF8 character set. We don't know what character set the 7.0.2 OSM/Weblogic/AQ uses. When we sent messages to the AIA QA2 AQ table we saw that everything under TEXT_LEN 4000 went to TEXT_VC. Over 4000 went to TEXT_LOB. This is fine for us.
Scenario 3:
We pointed our 6.3.1 OSM/Weblogic 9.2.1/Custom AQ Solution (which is part of our QA2 environment) to send messages to the AIA AQ table in our QA2 environment. The AIA database uses UTF8 character set. We don't know what character set the 6.3.1 OSM/Weblogic/AQ uses. When we sent messages to the AIA QA2 AQ table we saw that everything under TEXT_LEN 4000 went to TEXT_VC. Over 4000 went to TEXT_LOB. This is fine for us.
Scenario 4:
We pointed our 6.3.1 OSM/Weblogic 9.2.1/Custom AQ Solution (which is part of our DEVINT1 environment) to send messages to the AIA AQ table in our QA1 enviornment. The AIA database uses ALT32UTF8 character set. We don't know what character set the 6.3.1 OSM/Weblogic/AQ uses. When we sent messages to the AIA QA1 AQ table we saw that everything under TEXT_LEN 4000 went to TEXT_VC. Over 4000 went to TEXT_LOB. This is fine for us.