Questions on ASAP (MDB, EJB, JMS)
(Doc ID 2203309.1)
Last updated on MAY 17, 2022
Applies to:Oracle Communications ASAP - Version 7.0.2 and later
Information in this document applies to any platform.
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 
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document