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.
Long version:
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.
thanks/ranjix