We’ve all been there. You just finished a fresh clone from
Production to Test. The post-clone steps are done, the services are coming up,
but then you hit a wall: the Workflow Notification Mailer is stuck.
In a recent project for a customer, we observed this exact
scenario. After a successful clone, the mailer was perpetually stuck in a "Starting"
phase.
When this happens on a freshly cloned instance, it’s rarely a simple service glitch - it’s usually an "identity crisis" caused by stale configurations and stubborn database locks.
The Problem: New Credentials vs. Old State
After cloning, the Test environment still carries the
Production SMTP and IMAP settings. Naturally, you have to update these
fields—changing the server name which should point to correct smtp address and
a valid credential to match the test mailboxes
The issue? The Mailer tries to initialize using the new
credentials you just entered, but it gets tripped up by the "Running"
state and old control messages carried over from the Production snapshot. It’s
trying to start a new conversation while still holding onto the old one.
The Root Cause: "Identity Crisis"
When you clone EBS, the target database essentially wakes up
thinking it is still the source. Even after running adcfgclone and autoconfig,
the Workflow Advanced Queues (AQ) can still hold references or
"cached" states from the Production environment.
In this case, the mailer was trying to initialize, but it
was tripping over old control messages and orphaned process IDs that didn't
exist on the new Test server.
The Recovery Strategy: How We Broke the Deadlock
Clearing the Database Block
Our first instinct was to reset the status manually, but the
UPDATE statement hung. We realized a blocking session was holding a lock on the
fnd_svc_components table.
- The
Fix: We identified the blocking session and killed it at the database
level.
Once the lock was cleared, we
successfully forced the status to 'STOPPED'
To check
workflow mailer status:-
|
SQL> SELECT component_status FROM fnd_svc_components WHERE component_name = 'Workflow
Notification Mailer'; |
Find out
the session stuck with 'FND_SVC_COMPONENTS' component
|
SQL> SELECT
l.session_id AS blocking_session,
s.username,
s.osuser,
s.program,
s.status,
s.last_call_et AS seconds_in_wait FROM v$locked_object l JOIN v$session s ON l.session_id =
s.sid WHERE l.object_id in (SELECT
object_id FROM all_objects WHERE object_name = 'FND_SVC_COMPONENTS');
|
Kill the Session
If the query above returns a row, you need to
"kill" that session to release the lock. Replace SID and SERIAL# with
the values found from the query:
|
SQL> Alter system kill session ‘sid ,
serial#’ immediate; |
Update the
fnd_svc_components table forcefully as stopped.
|
SQL> UPDATE fnd_svc_components SET component_status = 'STOPPED' WHERE component_name = 'Workflow
Notification Mailer'; |
Reset the main component status
|
SQL>UPDATE
fnd_svc_comp_requests SET component_status = 'STOPPED' WHERE component_id = (SELECT component_id FROM fnd_svc_components WHERE component_name = 'Workflow Notification Mailer'); SQL> COMMIT; |
Also, you must check the OS level. If there is a "zombie" process, the Mailer will never start correctly even after the SQL update.
ps -ef | grep FNDCPGSC
If a process exists, use kill -9 <PID>.
Once above steps are done, try to Workflow notification mailer. It should get started.
