Skip to Content

Frequent message blocks in PI with out any error message

Hi All,

Frequently we are facing an issue of messages block in production PI environment. It happened continuously for three weeks, started on friday night and due to weekend blocked message count increases. So, on Monday morning we are restarting one of the PI server to clear the messages.

This issue is occurring when sending messages to specific third party system through JDBC adapter, but it shows no error messages.

I have seen in some of the threads and SAP notes where they are mentioning about setting "Pool waiting time" parameter in JDBC channel.But client is not accepting this without proper root cause analysis.

Anyone faced this issue? Need your thoughts/ideas.

Awaiting your reply.



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Feb 08, 2018 at 06:04 AM


    May i know how many receiver JDBC channels are running in production and what is the maximum concurrency set in those channels.

    when messages are getting blocked you can check below things to find out the root cause

    1) check the threads occupied by JDBC adapter in adapter engine status option in NWA(when messages getting blocked)

    If it fully occupied try to increase thread count.

    2)Increase the maximum connections value in resource adapter option in NWA where the connection details were maintained.



    Add comment
    10|10000 characters needed characters exceeded

    • Hi Pavan,

      Thanks for your response.

      We have 18 jdbc channels for various interfaces and maximum concurrency value is set to 1 for most of the channels.

      The default thread count mentioned for JDBC channels is 5. Can we increase more than 5?

      Up to what value we can increase the max number of connections to database in receiver JDBC channel?

      Usually this interface processes more messages daily. we want to set pool waiting time so that if there is any issue with target system, the interface fail instead of staying in "in delivering" status. But client is not accepting this as this is crucial interface for them, they fell that this timeout creates an issue when there is no issue with target system.