- Posted by: Sreenivas Mk
- Posted on: July 06 2005 05:15 EDT
I have a few questions about JMS with Java Processing.
( I ).. JMS Java Processing:
1a). i process put and get Text messages using JAVA with Websphere MQ APIs. And finally i calculate the processing capacity for a N number of Puts + Gets. I use Point-To-Point Messaging.
1b)This done with multithreading such that the destination queue is connected for M threads and performs N Puts + Gets for each thread, i.e. M*N in total.
( II ).. JMS Processing with J2EE :
2a). Second option is that, i use a application server (Websphere). And write EJBs... Message driven beans to process get messages (dependent on the message listerner service intervals) and i manually perform put within the onreceive method of MDB.
2b.) Here the App server does the threading instead, i.e. the number of MDBs that it can process is enabled by a setting in the App server and each MDB can process N Put+Get and with M number of MDBs, we have M * N messages in the destination queue processed.
This comparison is used to know which technology - Java or J2EE is more effective in terms of processing capacity, performance tuning and distributablity.
a) My question is that can we make such a comparison or not.
b) if we compare Java's result, for sure java has more processing capacity but its not tunable as a web app server. hence J2EE is better.
c) What disadvantages or advantages can be found in both the cases.
d) Can anybody give ideas for a better implementation for the comparison of JMS Processing.
I could provide some code and results from this work if it can make more clear.
Thanks in advance,
- JMS Processing with Java /J2EE. (Performance n configurability) by Ben Luget on July 07 2005 10:59 EDT
- JMS Processing with Java /J2EE. (Performance n configurability) by James Strachan on July 14 2005 09:04 EDT
In my experience you'll be hard pushed to beat J2SE for raw throughput. I think it comes down to a question of maintanance, development time and resource costs in terms of are you able to wrap J2SE driven JMS code with your required level of management and configuration.
With J2EE, if you need to integrate this as part of a supported and distributed solution obviously you'll immediately get all the benefits that an app server can bring with it e.g. configuration of MDB pool size, ability to tweak JMS settings, clustering ability, app server tech support etc.
If you pick the J2SE route apache commons pool or Doug Leas concurrent thread pooling open source may save you some dev time, if you're not already looking at them.
If you want high performance and to handle pooling of JMS connections, sessions & threads and transaction & exception handling and to support fast parallel processing of inbound messages then you really should use JCA.
As the above FAQ entry describes, you can use JCA inside J2SE using a POJO based JCA Container...