Ok, I set the jms-service.type to LOCAL, and that fixed our exception. Thanks for that tip, although I am still unclear as to what exactly that does.
The duplicate messages were still occuring however. I decided to double check the one last thing I had not double checked yet, and that was the driver sending the JMS objects over to the topic.
Instead of doing a JNDI lookup of administered JMS objects, the driver does self instantiating as described here:
<a href="
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWqdoc/SONEMSGQDEVG/adminobj.html">
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWqdoc/SONEMSGQDEVG/adminobj.html</a>
This was done to reduce the number of dependencies involved when connecting to Glassfish (only imq.jar and jms.jar are needed, instead of the other 6 additional Glassfish jars totalling ~25MB).
I decided to modify the driver to send data across using the traditional JNDI lookup of administered objects. Gave it a shot, and whammo, were back to doing nearly hundreds a second without issue at all. Tried it with multiple MDB instances again, and it still worked like a charm.
So, problem solved...sort of. We would still like to use our non-dependency heavy method of conecting clients to JMS, but we are unsure of what needs to be properly set. We are assuming it must be some sort of property on the ConnectionFactory, and are investigating it as I write this, but any hints would be appreciated!
[Message sent by forum member 'jamesdh' (jamesdh)]
http://forums.java.net/jive/thread.jspa?messageID=268615