This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes using tread.sleep in MDB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "using tread.sleep in MDB" Watch "using tread.sleep in MDB" New topic
Author

using tread.sleep in MDB

trupti nigam
Ranch Hand

Joined: Jun 21, 2001
Posts: 613
Hello all,

Is it ok to use Tread.sleep() in the MDB onMessage() method.Are there any disadvantages from performance point of view?

Thanks,
Trupti
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi trupti,

Is it ok to use Tread.sleep() in the MDB onMessage() method.

Technically speaking I believe it is. But I can�t see any reason why would you do that. Can you please explain your decision?

Are there any disadvantages from performance point of view?

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 think, therefore I exist -- Rene Descartes
trupti nigam
Ranch Hand

Joined: Jun 21, 2001
Posts: 613
Valentine,
I am having a specific queue assigned for the MDB. I am using Thread.sleep cause I have found one small defect in my application.
Ok Let me give you little Idea abut what I am trying to do.
I have to connect to remote Db in my application and request the missing parameters to process a resuest by user.
I have an Action class which sends request to the QUEUE , before that it locks the document in the DB table (separate table). At the front end the user sees a JSP page which refreshes after certain amount of time (few seconds). If the user click the back button of the browser he is taken to the main page of the application. and he will not see the response of his request. but the request has already been sent by him. In this situation the docuemnt will be locked in the DB forever if the response he receives ,for the request he sent is unsuccessful. Hence I want to take care of this situation in my MDB. When the MDB receives the message after few minutes from remote DB the MDB onMessage method will delete the row after certain amount of timelag (hence Thread.sleep) if the reponse is unsuccessful.

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.



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.


Thanks,
Trupti
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704

I am having a specific queue assigned for the MDB

First of all I�d like to make very clear one thing: execution queues and jms destination queues are not related concepts. A JMS queue is used for producing/consuming jms messages, while an execution queue is a weblogic internal queue for receiving incoming client request. Clients don�t interact with execution queues and they are part of weblogic�s message oriented architecture. Please don�t confuse them.
Second of all I�m not sure if I totally understand your design, but it occurs to me that your client needs to wait for receiving the response, after posting a message to a jms queue. This however defeats the purpose of MDBs and asynchronious message processing. You might like reconsidering your design though.

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.

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.
trupti nigam
Ranch Hand

Joined: Jun 21, 2001
Posts: 613
Valentin,

Thanks for the replies.
I am using another approach in my code and that doesn't involve using thread in MDB.
The information provided by you was really useful.

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.


Thanks,
Trupti
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
You're very welcome trupti
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: using tread.sleep in MDB
 
Similar Threads
Issue with jboss tibco integration after tibco EMS restart
system exceptions
is it possible to semd messages from MDB to MDB
[MDB] K&B, What technique is better ?
ejb-jar file 's content