The JBossTopic[com.bluemartini.DBUtilTopic] seems to come from JBossTopic class, toString method.
Left to figure out the "not processed" part, keep digging...
I guess it's your MDB configuration problem. Is your subscriber durable or not?
It's not impossible that my MDB config is wrong, it's bothering that same configuration works consistently in weblogic and websphere but not in jboss. As I said, I did try to make the subscription durable, see the MDB's ejb-jar.xml underneath, and DID NOT HELP.
I also tried to make the messages persistent, but at that point the text in the system.out became "10:10:38,736 INFO [STDOUT] Warning: Message to JBossTopic[com.bluemartini.DBUtilTopic] not processed: delegator->JBossMessage:PERSISTENT, deliveryId=1", and the JMS message was still delivered 2 times out of 3.
Frankly there is a certain hint of flakiness coming out of this issue, in regards to JBoss capability of working with JMS. Hope I'm wrong and indeed something in our app is interfering with the JMS (although don't really see how...)
P.S. Again, a hint towards where in the sources is the text "Message to JBossTopic" constructed would really help. At that point I could try and debug.
the ejb-jar.xml<?xml version="1.0" encoding="UTF-8"?><ejb-jar id="ejb-jar_ID"version="2.1"xmlns="http://java.sun.com/xml/ns/j2ee"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"><display-name>remotedesktop-JAR</display-name><enterprise-beans><message-driven><description> db util mdb </description><display-name>DBUtilTopicMDB</display-name><ejb-name>DBUtilTopicMDB</ejb-name><ejb-class>com.bluemartini.jms.mdb.DBUtilTopicMDB</ejb-class><transaction-type>Bean</transaction-type><message-destination-type>javax.jms.Topic</message-destination-type><activation-config><activation-config-property><activation-config-property-name>subscriptionDurability</activation-config-property-name><activation-config-property-value>Durable</activation-config-property-value></activation-config-property></activation-config></message-driven></enterprise-beans></ejb-jar>
Ok, after a week of digging, I finally think I understand what's going on and I hacked something to fix the issue.
Short version, IMO is a bug in how JBoss shares JMS messages objects between subscribers on a topic.
I have several apps, with MDBs, which subscribe to the same topic. The apps run in the same server (JVM), but obviously each in its own app classloader (the MDBs, when called, have as classloaders the EAR app classloader). This is good. The JMS message object type which I get in the onMessage implementation is org.jboss.jms.message.BytesMessageProxy (the message was supposed to be a BytesMessage). I get different instances of BytesMessageProxy in the different MDBs. This is ok. Here comes the bad part. The MessageProxy (BytesMessageProxy extends this) contains a field message which is a JBossMessage. The bad part is that each of the different instances of proxy class contains same JBossMessage object. So, now, my MDBs start reading from the proxy, which in turn read from the JBossMessage. Since I have a quad core, the reading is pretty fast, and the "second" MDB starts reading before the first finished reading and resetting the message. This makes the second MDB make a read after the end of the payloadByteArray (which is a byte array containing the BytesMessage), which results in a MessageEOFException thrown from line 169 in method readByte in JBossBytesMessage class.
So, in conclusion, IMO sharing the same JBossMessage object between the subscribers will ALWAYS be a problem.
My hack. In my onMessage method, I can't really put a synchronization block depending on the BytesMessageProxy (since is a new instance for each MDB onMessage call). But I don't have access to the contained shared JBossMessage object, so I put a synchronization block depending on BytesMessageProxy.getJMSMessageID object, which is the string representing the message's id. Since the JBossMessage shared has only one ID, then my readings will wait for the lock on the ID. This, at least, fixed my issues. Not happy at all with the implementation, if someone on JBoss JMS team reads this, please consider it for a possible bug.