Is it ok to use Tread.sleep() in the MDB onMessage() method.
Are there any disadvantages from performance point of view?
I think, therefore I exist -- Rene Descartes
Originally posted by Valentin Tanase:
Hi trupti,
I strongly believe so. Different containers might use a different approach, but weblogic for example uses execution queues in order to process server jobs. Each execution queue has a number of associated execution threads that weblogic pools for that execution queue. Every MDB is also associated with an execution queue, through deployment descriptors. If no queue is specified then weblogic will use the default one (known as weblogic.kernel.Default). Now you probably get the whole picture: when messages arrive at the associated destination the container tries to find a MDB instance to handle the message. It will also try to get an available execution thread from the pool to do the job. You might also notice that many other applications will share the same execution queue and therefore releasing and returning the threads to the pool after a short period of time is imperative. If your MDB calls Thread.sleep() it might result in reserving that thread for a very long period of time and it might affect other applications as well. Finally you might define a special execution queue for your MDBs and avoid bumping into other applications, but this still might raise performance issues. Finally I can only advice you to reconsider your design.
Regards.
I am having a specific queue assigned for the MDB
Do you see any harm under this situation?
I don't see any as the time lag is only 1 minute.
I wanted to donfirm if there is going to be real performance bottleneck.
I think, therefore I exist -- Rene Descartes
Originally posted by Valentin Tanase:
Yes I do. If your MDB is enlisted within a transaction then your transactions will be a huge bottleneck in your system. Also you might consider that your bean instance will be reserved for one minute, which will break any scalability goals. It might not be a problem if your application has 10 users, but it will overkill a highly available system. Finally you might consider the point I made initially: your MDB will reserve a thread from the execution queue (not jms queue) for a minute, while other applications will starve. Even worse, if you don�t specified an execution queue, weblogic will use the default one that is used by many applications, including weblogic internal processes. To conclude I�ll tell you that you might get away with this if your application is not deployed to a highly demanding environment, but you might face a big risk factor otherwise.
Regards.
I think, therefore I exist -- Rene Descartes
What's brown and sticky? ... a stick. Or a tiny ad.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|