There is a way to restart just the UBE queue in EnterpriseOne. If you are faced with a situation where submitted jobs are not processing and the jobs are sitting in a waiting status you can get the queue restarted without bringing down the entire E1 system, allowing interactive users to continue their work.
In older (prior to 8.9) releases the queue was a separate Windows service called JDE Update 4 B733 Queue or something similar. This service could be stopped and started independently of what was then called JDE Update 4 B733 Network or the "Network" service. This made it easy to restart the queues without bothering the main service. In the 8.9 release however, the queue service was redesigned and turned into a kernel under the main E1 service, greatly complicating the targeted restart of the queues but not making it impossible. Here's how:
Go to the JDEdwards\E812\DDP\log directory and search for files containing the text QUEUE KERNEL. This will give you the queue kernel PID in the file name (i.e. jde_9188.log). You will (should) have only one queue kernel. Go to Windows Task Manager and View/Select Columns and add the PID column. You can kill that PID and the next time a job is submitted the Queue kernel will be restarted.
There are also ways to move jobs from one queue to another but that's a post for another day.
Subscribe to:
Post Comments (Atom)
Email
Twitter
RSS
8 comments:
Hi Jeff,
Just to confirm, even if we keep maxNumberOfProcesses=2 and having multiple queue, still we will have only one kernel log ie unique PID?
Thanks in advance
Gmanda
Actually with 8.9 and above for the QUEUE KERNEL
maxNumberOfProcesses should always be set to 1. If you set it to 2 , then your single threaded queues could potentially run more than one job
Tonio is correct - you should set maxNumberOfProcesses=1 for the Queue Kernel. This will result in the single queue kernel that I referred to.
Be aware that the Queue Kernel is different than the UBE Kernel. The UBE Kernel can have multiple processes.
Jeff,
Have you ever found killing the Queue Kernel processes affecting jobs that were already in a processing state? Theoretically it should not as once the Queue kernel has launched the runbatch process it is handed over to the UBE kernel , and the Queue Kernel only comes into play when the job is done and the status needs to be updated.
I have had some scenarios where I have some jobs in a P state, and the queue kernel not processing new jobs (they stay in Wait). And sometimes killing the queue kernel kills the runbatch processes too. This was on a Unix server though and there was a parent child relationship between the Queue kernel and the runbatch processes, so I guess that would make sense. In some cases there was no parent child relationship and killing the Queue kernel was fine.
Actually the UBE Kernel takes the initial request, inserts a record into F986110 with a 'W' status and messages the Queue Kernel. The Queue Kernel launches the job under a Runbatch process and then monitors the job. It is possible that killing the Queue Kernel would cause a processing job to not get an updated status if the Queue Kernel is down when the job's status changes.
I haven't seen a scenario where killing the Queue Kernel ended running jobs but that doesn't mean it won't happen. It would certainly be easy to test.
Hi Jeff,
Conceptually Call object and Metadata kernel goes into zombie. We have B7334 with SP24 tools release. I have doubt if queue process is going into zombie then possible cause would be either call object kernel will be going into zombie. Can IPC also cause for it? Deadlock situation or memory leak can also be reason. Please provide your views for all the above scenarios.
It is quite common for Call Object kernels to zombie. Check out the document E1: KER: Troubleshooting E1 Kernels [ID 1321633.1] https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=REFERENCE&id=1321633.1
Also, MetaData kernels dying is a known issue, contact Oracle support.
Post a Comment