If the processes do not match for Output Post Processor

CONCURRENT_QUEUE_NAME RUNNING_PROCESSES TARGET_PROCESSES MAX_PROCESSES MIN_PROCESSES
-------------------- ----------------- ---------------- ------------- -------------
FNDCPOPP 6 3 3 3

Check Internal Manager log

Starting FNDCPOPP Concurrent Manager : 14-APR-2015 17:26:18
Starting FNDCPOPP Concurrent Manager : 14-APR-2015 17:26:18
Starting FNDCPOPP Concurrent Manager : 14-APR-2015 17:26:18
Process monitor session started : 15-APR-2015 14:05:45
Internal Concurrent Manager found node APPROD to be down. Adding it to the list of unavailable nodes.
Internal Concurrent Manager found node DBPROD to be down. Adding it to the list of unavailable nodes.
CONC-SM TNS FAIL
Call to PingProcess failed for XDPCTRLS
CONC-SM TNS FAIL
Call to PingProcess failed for XDPQORDS

Call to PingProcess failed for FNDOPP
CONC-SM TNS FAIL
Call to PingProcess failed for FNDOPP
CONC-SM TNS FAIL
Call to PingProcess failed for FNDOPP

Starting FNDCPOPP Concurrent Manager : 15-APR-2015 14:08:11
Starting FNDCPOPP Concurrent Manager : 15-APR-2015 14:08:11
Starting FNDCPOPP Concurrent Manager : 15-APR-2015 14:08:12

Read more...

Cause:

Blocking sessions occur when one session holds an exclusive lock on an object and doesn't release it before another session wants to update the same data. This will block the second until the first one has done its work.
From the view of the user it will look like the application completely hangs while waiting for the first session to release its lock. You will often have to identify these sessions in order to improve your application performance to avoid as many blocking sessions as possible.

Solution:

The following query shows all the blocking sessions which can help you to identify the problem.

col WAIT_CLASS for a12;
select blocking_session,sid,serial#,wait_class,seconds_in_wait,status from v$session where blocking_session is not NULL order by blocking_session;
Read more...