Stuck Threads (BEA-000337) using CreatePSROrderSync XML API method
Last updated on APRIL 10, 2018
Applies to:Oracle Communications MetaSolv Solution - Version 6.2.1 and later
Information in this document applies to any platform.
*** Reviewed for relevance on 05-MAY-2015 ***
The createOrderByValueRequest XML API causes blocking/blocked threads in a multi-threaded scenario. The application server initializes the CacheManager at start-up to cache the Custom Attributes stored on the database. Any new Custom Attributes added to the database are cached at the next caching interval configured in the gateway.ini file or when the server is restarted. However, the very first execution of the createOrderByValueRequest XML API causes the CacheManager to build the cache again. Subsequent executions do NOT run the CacheManager.
The behavior occurs because all the orders in the multi-threaded scenario are treated as a "first" execution. The CacheManager queries run very quickly, but they are executed often and the threads are constantly taking turns blocked/blocking each other until their processes have completed. High CPU utilization can be observed during this time. A few of them may actually abort and those orders will not be created.
The WebLogic server eventually reports these threads as STUCK and analyzing several thread dumps shows them taking turns blocking each other "waiting to lock <0xb38d50c0> (a oracle.jdbc.driver.T4CConnection)". The data below is an example of of the problem where thread '12' running the BbPpCaUsageLangDataQuery.getData query for CacheManager.buildCache is blocking threads '20' and '16' that want to run the same query.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms