Performance really depends on how you're persisting messages. Then it depends more on database performance mostly. The size of the message isn't incredibly important, if less than 100K or so. Do your own benchmarking by configuring a vanilla JBoss and sending messages using a couple clients.
As for clustering, take a look in the WIki.
well, lets say that in my test setup an MDB instace just picks up a message object from the queue, checks 3/4 fields in it, does some computation (a mathematical hash, say), and based on hash-value passes it on to one of the various session beans. in my case, the recipient session bean (stateless) does a lookup of a CMP'd table in an entity-bean, and based on looked up value, creates a response message and sends it back via JMS to the external "original message source". atleast at an application level, no DB transaction is involved, only message processing. with such a test-setup, are there some performance figures available ? does the above description make any sense (based on my tid-bits' type of information about J2EE and the various allied technologies).
BTW, could you plz explain what you mean by "configure a *Vanilla* JBoss"... is JBoss available in various flavours ??
thanks & best regards,
Strawberry and Chocolate are also available.
Speaking of which, the proof is in the puddling: You need to build it to understand the performance issues. It would only take a few days to build it, then run it. You'll have real numbers and no bullshit.
As an aside: I don't know the point of sending a message to JMS and waiting for a reply. You might as well have the session bean do the computation itself. Sounds pretty silly to me to add all that overhead.
let me explain the idea which looks silly --
i have couple of native (c++) apps that are the message sources. the message consumers are the session beans themself which implement the logic that acts upon the message and then sends a response back to the respective native apps. so if i say that native apps are below the containers, then on the way up (ie. from native apps to the session beans) i use the point-to-multipoint delivery model, and on the way back, to make sure that the response message comes back to the originating native app only, i use point-to-point delivery. the reasons for bringing in JMS in this case is fault-tolerance and load-distribution, i.e. i'd like to mave multiple containers reachable on different hosts from each native app.
now does this make sense, or is it still a silly idea and an overhead ? if it is, could you suggest me a more optimal way, given the objectives.
I also want to know more about what exactly you mean in "Do your own benchmarking by configuring a vanilla JBoss and sending messages using a couple clients. "
It should take you only a few hours to download JBoss, start it, create and deploy a MDB, a JMS client and send messages to your server. You can measure throughput by calculating using some sort of static counter in your MDB.