Last updated on MAY 30, 2017
Applies to:JD Edwards EnterpriseOne Tools - Version 9.1 and later
Information in this document applies to any platform.
UBE was submitted to server and the job processed for a long time until it was terminated via timeout. Package build has been completed and deployed successfully for several times but still the issue persists. After a few round of tests and troubleshooting, it was found that there are a lot of job submission records in F988259 (MDK table for UBE locking).
According to "E1: PKG: Quick Package Deployment Functionality - From EnterpriseOne TR 184.108.40.206 Onwards (Doc ID 1093018.1)"
... If a UBE in the package is being submitted during the time of the deploy, it will see the lock is set by package build and will add a record to the F988259 table (new table). These UBEs are queued up until the deploy is done and the lock is released by the package deploy. Once the package deployment is finished, releasing the locks, the Metadata Kernel processes each of the UBEs found in the F988259 table. The UBEs in the table will only be the UBEs that are in that package. There is a lock set for each UBE in the package, so if there are three UBEs in the package, we set three locks...
There is no any job is being submitted during the time of the deploy.
Additionally, after removing all the records in F988259 table and submitting an UBE via server, new records are inserted into the F988259 table when job failed.
The issue can be reproduced at will with the following steps:
1. Submit report via server.
2. UBE processed for a long time and errors out due to timeout.
JDEDEBUG logs stated the followings:-
Sep 30 10:37:00.464036 - 10584/6792 MAIN_THREAD Waiting for UBE [R554204] to finish deploying had failed for job .
Sep 30 10:37:00.464037 - 10584/6792 MAIN_THREAD Failed to load job spec cache for job 259157 report R554204_UEMB0005. Cannot load specs for UBE. Please remove the cache directories for this report under the <install dir>\PY910\spec\runtimeCache directory and rerun the report. If errors persist, check the metadata kernel logs for more information (object could be missing from package, failed to access package database, etc.)
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms