Last updated on FEBRUARY 02, 2016
Applies to:Oracle Communications Messaging Server - Version 5.2.0 to 7.0.5 [Release 5.2 to 7.0.0]
Information in this document applies to any platform.
A custom channel master program, written by the customer to perform customer-specific action - using the MTA SDK (pdf) - when dequeuing from their application-specific channel, often does not run as many threads as expected.
If there are several messages in the channel queue when job_controller starts the process, it will start several threads and dequeue messages quickly - for a short time.
But when there are no messages in the queue and one arrives and job_controller starts the master program, if several more arrive while that first process is running, a new process is started. The new process starts several threads and seems to behave as expected - for a short time. The original process eventually reduces to only a single thread. Eventually the additional processes started reduce to only a single thread. So eventually, if there is a steady stream of messages enqueued to the channel, the maximum number of processes allowed for the channel are all running only a single thread - significantly fewer threads than required to keep ahead of the number of incoming messages.
If you restart job_controller while there are many messages in the queue for this channel, it will start multiple processes, all running multiple threads and they will dequeue quickly - for a short time - until they all reduce to only a single thread.
These details can be observed with the prstat or ps commands to see the number of threads. Also the imsimta qm sum -data output shows a large number of messages "Pending" but very few "Active".
The custom channel program is a new development. This behavior was noticed as soon as they began testing it under load.
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