Questions on ASAP (MDB, EJB, JMS) (Doc ID 2203309.1)

Last updated on NOVEMBER 18, 2016

Applies to:

Oracle Communications ASAP - Version 7.0.2 and later
Information in this document applies to any platform.

Goal

Questions on JMS Queues, Work Managers and MDB for ASAP

Q1. Application Specific Timeout – Currently MDB has the transaction time out to 4800 seconds i.e. 80 minutes , is there any reason this value has been setup this high in the descriptor and is there any harm in setting it up to a lower value.
a. This is defined in srp.jar  META-INF  weblogic-ejb-jar.xml [4800]
b. Is this okay to modify this value by ourself or is this something Oracle need to provide as a patch ?

Ideally, there are no transaction for this Bean which are running for 80 minutes. Currently due to the bug in getOrderByKey API (If Primary Key is received as % then API call never finishes) , it causes the thread to run for longer than expected and thread tries to pull all the WOs related details from the database , as a result Weblogic crashes with out of memory error. Whole idea of reducing this value is so Weblogic can stop such long running transactions and not result in complete weblogic shutdown.

Q2. Work Manager – Currently deployed EJBs that come with the ASAP installation do not have any work managers defined. Are there any plans to have these EJBs configured in separate work managers based on the functionality. This could  be one way to have different components working in different work managers and effectively applying  thread policies for each one of them.

Also, if components/Beans can be configured in different work managers , we can apply Weblogic thread policies in a different  manner e.g. Restart the work manager if there > X number of stuck threads etc…

Q3. JMS Queue – The existing  JSM queue has an expiration policy set to “Discard” , that means after a configured number of retries , messages will be deleted and there will not be any history of them. Is it okay to have this setup to forward to the ErrorQueue ?

Here we are proposing to use the forward to the Error Queue with a  redelivery limit. This is not to necessarily use the Weblogic ErrorQueue, but imaybe a custom queue. This is to make sure that we do not loose any messages. Today, if after a number of retries, the message is not processed , it will simply be discarded without any history. With this configuration , we can forward such messages to a Queue where a manual action , investigation can be carried out. Its understood that housekeeping & monitoring of this queue need to be done in order to not  have large number of message in this queue.
 

Solution

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