Author |
Message
|
srinivasACN |
Posted: Wed Sep 07, 2005 12:36 pm Post subject: Websphere App Server 5.1.1.5 & MQ - Dequeuing SLOWLY |
|
|
Apprentice
Joined: 08 Aug 2005 Posts: 43
|
All,
i am running an applicaton on Websphere Application Server 5.1.1.5 and Websphere MQ 5.3.
I have an MDB called InboundMDB which dequeues messages, does some processing and inserts into the database.
Problem I am having is, after a certain while of processing after starting the application (~ 2 - 3 min), the application dequeues messages at a rate of almost 1 message/20 min.
I am assuming I am missing some configuration in Websphere Application Server or something. Please let me know if you can help me out. Thanks in advance. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Sep 07, 2005 1:04 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Well first you'd have to determine where the bottleneck lies...
Frankly I'd be surprised if it was MQ.
Depending on your installation it can be a multitude of things including but not limiting to:
Network
Database
Process inside the MDB
Enjoy  |
|
Back to top |
|
 |
srinivasACN |
Posted: Wed Sep 07, 2005 1:42 pm Post subject: |
|
|
Apprentice
Joined: 08 Aug 2005 Posts: 43
|
The workflow is fine when only a few messages reside on the queue. We are stress testing with 70,000 messages on the queue and this is where the problem is observed.
Any suggestions? |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Sep 07, 2005 7:36 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Do you have a message selector on the queue ?
One that does not involve message id or correlation id or does not start with
"MessageID=""ID:......."" " and a bunch of hex chars....???
Enjoy  |
|
Back to top |
|
 |
RogerLacroix |
Posted: Wed Sep 07, 2005 8:25 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Also, do you load the messages to an internal JMS store? At a client site, someone had configuraed a WebLogic domain to have the messaging bridge retrieve all outstanding messages then the app would retrieve the messages from the JMS store.
This was done for so-called speed. It brought the server where WebLogic was running to its knees because it was loading 250,000 messages and each message was about 15KB.
Regards,
Roger Lacroix _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
srinivasACN |
Posted: Thu Sep 08, 2005 5:38 am Post subject: |
|
|
Apprentice
Joined: 08 Aug 2005 Posts: 43
|
RogerLacroix wrote: |
Also, do you load the messages to an internal JMS store? |
Hey Roger, I am not sure where to check for this. I am not aware of any configuration we set to load the message to an internal store. Can you please enlighten me as to how go about to check this. I will research the topic myself as well. Thanks again.
fjb_saper wrote: |
One that does not involve message id or correlation id or does not start with "MessageID=""ID:......."" " and a bunch of hex chars....???
|
Hey fjb_saper, we do not use any message selectors. Since the app is very highly dependant on performance, we designed to not use any message selectors.
Our messages are persistent, once again I know this affects performance BUT these are customer reliant messages, so we cannot lose them.
Any other suggestions? Thanks again guys I really appreciate it. |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Sep 08, 2005 5:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Are you sure that the consumer is a) not BROWSING, and b) COMMITTING the gets?
If it's browsing, or not committing, then the queue depth is growing over time, and it takes longer to get the "next" message. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
srinivasACN |
Posted: Thu Sep 08, 2005 6:18 am Post subject: |
|
|
Apprentice
Joined: 08 Aug 2005 Posts: 43
|
jefflowrey wrote: |
Are you sure that the consumer is a) not BROWSING, and b) COMMITTING the gets?
If it's browsing, or not committing, then the queue depth is growing over time, and it takes longer to get the "next" message. |
Hey Jeff, my MDB transaction management is configured to be at the Bean level. Once the onMessage() method completes, I assume the commit is handled by the Application Server? I am new to MDB development so pardon my limited knowledge. |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Sep 08, 2005 6:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I think that beanManaged means that the AppServer doesn't do the commit for you. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
srinivasACN |
Posted: Thu Sep 08, 2005 6:27 am Post subject: |
|
|
Apprentice
Joined: 08 Aug 2005 Posts: 43
|
jefflowrey wrote: |
I think that beanManaged means that the AppServer doesn't do the commit for you. |
Ok just did some googling. You are absolutely correct here. I will look into this an hopefully be able to resolve my issue. Thanks Jeff. |
|
Back to top |
|
 |
srinivasACN |
Posted: Thu Sep 08, 2005 10:48 am Post subject: |
|
|
Apprentice
Joined: 08 Aug 2005 Posts: 43
|
Alright so I implemented a JTA Transaction and changed my database Hibernate Transaction to JTA Transaction and am commiting after doing everything in my MDB.
Still very slow performance. Any other suggestions? Thanks for your help. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Sep 08, 2005 1:26 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
if it takes up to 20 minutes to process one message you should be able to do some logging giving time to the second or milisecond:
a) on MDB entry (onMessage entry)
b) start processing of message
c) end processing of message
d) before hybernate call
e) after hybernate call
f) before exit of the onMessage method of the MDB
h) on any exception being raised ?
This should help you pinpoint as to where your bottle neck is.
Can you please as well specify whether your MQ connection is client or server type and whether the QMGR is on the same machine as the WEB server.
Thanks
F.J. |
|
Back to top |
|
 |
|