cancel
Showing results for 
Search instead for 
Did you mean: 

JDBC Receiver - TobeDelivered

baskar_ramasamy
Participant
0 Kudos

Hi Experts,

We have a  PROXY-PI-JDBC scenario which was working fine for past few months and now we are getting  "To be delivered"  status for all our JDBC receiver messages and we observed that AF is slowly processing the messages.

Also Please note the following parameter :

Maximum Concurrency to 4.

No Changes in Receiver database

BC_MSG Size = 27,000

We are planning to do a JAVA Restart, will this affect the 10,000 messages that are in AF Queue.

Is there any other way to do a Adapter Refresh ?

is there any way to analyse adapter slowness ?

Thanks,

Baskar.R

Accepted Solutions (1)

Accepted Solutions (1)

rajasekhar_reddy14
Active Contributor
0 Kudos

JDBC not processing messages to DB? or messageres are flowing in slow pace?

1)If messages are in To be delivered state and DB chanell processing messages in slow pace means resend tobe delivered status messages in RWB.

2) If messages are in To be delivered state and DB chanell not processing messages means resend JDBC adapter status moved to dead lock, this behaviour you might obeserve when JDBC channel load is high and Target DB system response time is low.

Temporary Solution:

1)Restart JDBC Adapter service in NWA and check results,if still same then definetly you need to restart JAVA Stack.

Permanent Solution:


By defualt JDBC adapter uses 5 threads to process messages to DB system, so you can increase this value in NWA ,increase value to 20 and set maximum concurency value in JDBC receiver adapter.

Thank you,

Raj

baskar_ramasamy
Participant
0 Kudos

Raj,

i tried re starting the adapter, but no luck.

rajasekhar_reddy14
Active Contributor
baskar_ramasamy
Participant
0 Kudos

Raj,

We have re-started the java stack, But still all the messages are stuck.

We observed "DispatchDisp" queue is heigh, please refer below screen shot.

When we manually re process the messages stuck in queue, again the new messages are getting stuck.

Please help on this.

allamudi_loordh
Active Participant
0 Kudos

Hi Baskar,

Try identifying some old message (initial) which got failed by checking the order in message display tool. then cancel the first message. After that you can reprocess all these message one by one.

Regards,

Loordh.

Answers (6)

Answers (6)

baskar_ramasamy
Participant
0 Kudos

Thanks a lot to all in helping this issue resolved, It was a production issue and high priority.

Issue resolved as per Loordh suggestions.

Thanks,

Baskar

markangelo_dihiansan
Active Contributor
0 Kudos

Hello,

Please check SAP Note 831162  - FAQ JDBC Adapter question 24.

Messages processed by JDBC receiver are in delivering state

forever

Q: During JDBC receiver message processing I see that some messages

are in "delivering" state forever. How do I solve this?

A: Please set the receiver channel configuration Exactly Once

handling parameters as "local" and "redo".

The configuration setting "local" and "error" setting is some

times prone to deadlock situations at the DB table level.24.

Hope this helps,

Mark

baskar_gopalakrishnan2
Active Contributor
0 Kudos

You might want to increase the maximum number of concurrency for jdbc receiver still more and see if that helps. One delayed message processing block the following messages that are in the queue and this continues for sometime and finally ending up more messages staying in the queue forever. Typical restart the java stack is the temporary resolution for now.

baskar_ramasamy
Participant
0 Kudos

Baskar,

Will the java stack restart reprocess the tobedelivered messages? or the messages will be deleted.

Thanks,

Baskar

baskar_ramasamy
Participant
0 Kudos

Manigandan,

This is PROXY to JDBC , we dont have sender channel

Thanks,

Baskar

manigram
Active Participant
0 Kudos

HI,

Stop your sender channel and let all message to process, then restart the java stack.

Regards,

Manigandan

allamudi_loordh
Active Participant
0 Kudos

Hi Baskar,

Try batch job and restart the message.

Regards,

Loordh.