• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

using tread.sleep in MDB

 
Ranch Hand
Posts: 647
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
trupti nigam
Ranch Hand
Posts: 647
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 647
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're very welcome trupti
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic