WISD - Understanding Maximum Queue Wait Time

MT · Post by MT » Mon Sep 10, 2012 9:34 am

Hi,

we ran into problems with our WebServices in a load test scenario but the problem seems well known if I look at following pages:
http://www-01.ibm.com/support/docview.w ... wg21449932
http://www-01.ibm.com/support/docview.w ... wg21441350

Here is a error message I got (for reference and search):

Code: Select all

9/6/12 17:09:01:021 CEST] 000000c6 RemoteExcepti E   CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "VTPWS003Result" on bean "BeanId(ISD_VTPSelectionApp7742273956876416795.ear#soapbinding.jar#VTPExternSOAP, null)". Exception data: javax.ejb.EJBException: nested exception is: javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 0x0 No; nested exception is: 
            org.omg.CORBA.TRANSACTION_ROLLEDBACK: javax.transaction.TransactionRolledbackException:  ; nested exception is: 
            javax.ejb.EJBException: nested exception is: javax.resource.ResourceException: Maximum Queue Wait limit of 180000 milliseconds exceeded.  vmcid: 0x0  minor code: 0  completed: No

We have adjusted the Maximum Queue Wait parameter a couple of times but I would like to understand it a little better and I hope someone can help me with a good and understandable definition how the queue works.
Here are some questions where I did not find an answer in the forum or the documentation:
1. How many queues do I have for a single WebService?
I assume one but it could also be one per Job Instance....
2. When will a job be removed from the queue - after it starts processing
or after it finishes processing?

many thanks in advance

eostic · Post by **eostic** » Mon Sep 10, 2012 9:46 am

There are quite a few buffers involved with ISD and some of them evolved over time and over multiple releases to handle different parts of the traffic load. I don't remember off-hand some of the exact rules, but the queue (in its own tab) with its wait time, used to be at the Services tier, as it also controls the type of load balancing that you might have between multiple DS Engines (note the pull down for round-robin, or algorithm --- choose RR if you have multiple engines).

If you are timing out, increasing it is a fine thing to do, but it is also a very good indicator that it is time to increase the number of instances for that particular Operation... Play with that value until you get the high traffic number flowing thru and all your services and their clients are getting serviced. Then make that value your "minimum.".

Ernie

MT · Post by MT » Mon Sep 10, 2012 9:57 am

Hi Ernie,

eostic wrote:If you are timing out, increasing it is a fine thing to do, but it is also a very good indicator that it is time to increase the number of instances for that particular Operation...

We have done this also for several times.
Playing araound is exactly what I try to stop now because after every increase the load test was adjusted as well....
I need a good and exact definition about the wait time - see my above questions in order to calcualte a realistic value.

So does your answer mean that there is only one queue?

When will the request be removed from the queue?

Thanks in advance

eostic · Post by **eostic** » Tue Sep 11, 2012 5:14 am

Somewhere I have notes on the architecture, but I am travelling this week and won't have access to them. I believe that you will accomplish the most by carefully working with your test scenarios and playing with the settings. Increasing the instances is generally the best thing that you can do, so that your requests are being handled as soon as possible.

Keep in mind that you can also play with the "Request Limit" at the Provider Properties tab. This is another "wait" buffer that, if memory serves me correctly, is over at the ASBNode side.

I'd like to give you a more calculated approach, but the scientific method of playing with each of these in a controlled manner is going to get you the best results in the end. There are so many variables.

Ernie