More than a lakh messages in scheduled status in PO PROD

[harish_babu5]

Hello everyone,

I have lots of messages in the PO PROD system in scheduled status. My PO system was up from last Jan and it was working fine till Dec 25th. Even now the messages that are sent to PO from third party systems like AS2 and JDBC are successfully processed in PO and sent to ECC system. There is no delay in those interfaces.

However when the flow is from ECC --- PO ----- AS2/JDBC. The messages are in scheduled status. The messages that are processed by AS2 receiver adapter and JDBC receiver adapter goes to scheduled status.

I have around 9 ECC - PO - AS2 scenarios, and I used different CC for each senario. So shouldn't it work as they are all using different receiver AS2 communication channels?

And in JDBC, I have many interfaces. There is one interface that processes a lot of messages. I am using a seperate com channel, JDBC Receiver for that. I am using a JDBC Receiver CC for around eight interfaces and I am using another JDBC receiver channel for another six interfaces.

Altogether I have five JDBC Communication Channels in the system. Three CCs are for seperate interfaces and two CCs are shared by many interfaces.

In Message Mapping if I select a message under the Receiver Interface, I see the Sender interface name. If I open the message and resend it, the status is TBDL, next time I can see the receiver interface name under receiver interface name tab in Message Monitor but still the status is TBDL. If I resend that message again, it is delivered. I can't certainly do this process for one lakh messages.

Any idea?

[harish_babu5]

I have set the value for XPI Service : Messaging System

messaging.system.queueParallelism.maxReceivers 0

still one interface is blocking the whole adapter

There are more than one lakh messages in scheduled status in one particular JDBC Com channel, so I set the Maximum Concurrency for that as 5.

Now the other six receiver com channels are not at all working. I changed the max concurrency to 1 for that channel still the six receiver jdbc CCs are not working..

The interface with more than one lak messages is working.. but other receiver jdbc CCs are not

The sender JDBC channel is working fine

[former_member186851]

Harish,

Then might be problem with third party side as well.

The processing time for executing query might be slow at the JDBC side which might create the delay.

[anupam_ghosh2]

Hi Harish,

               Did you discuss this issue with target servers?? There might be issues at the target server end for which messages are failing. Secondly pls check with BASIS team if available run time memory of PI/PO server is sufficient or not.

Regards

Anupam

[harish_babu5]

Hi Anupam

PO system was fine till few days ago. Till Dec 26th, it was working fine.

I will, anyway, check with the BASIS team

Strangely, even my receiver AS2 scenarios are not working. At the same time, SOAP receiver channels configured for ECC system are working fine.

I have seven receiver JDBC CCs and only one is working. It is the one with more than one lakh messages in scheduled state

Harish

[anupam_ghosh2]

Hi Harish,

                   Low memory causes messages to go to scheduled status. Thus first check with BASIS team before coming to a conclusion. If memory is not an issue. Try for server restart. Check for errors in communication channel log or NWA log.

Regards

Anupam

[former_member186851]

Hello Harish,

Try increasing the processing threads for JDBC adapter.

[harish_babu5]

Hi Raghu

One interface is processing more than a lakh messages a day.

For that interface, I have configured receiver JDBC CC like this

Max Concurrency 3

Disconnect from Database After Processing Each Message unchecked

For remaining six receiver JDBC CCs, I configured this way

Max Concurrency 1

Disconnect from Database After Processing Each message checked

Exactly Once Handling

Persistence Local

Conflict Resolution Redo

This is same for all seven interfaces.

I have entered logSQLStatement true

Wonder whether this will add to the time delay in message processing

Harish