Adapter Engine delay reading Queue

[Former Member]

Hello,

Can anyone help me with the following:

Since a day or two we have been experiencing delays in message processing in the adapter engine. The delay is always in the same step when looking at a message via MDT:

2007-05-21 14:30:25 Success Message successfully put into the queue.

2007-05-21 15:33:33 Success The message was successfully retrieved from the receive queue.

Here there is a one hour gap for a step that normally takes only 1 second. The delay appears and disappears without intervention. On friday there was a delay of 45 minutes and yesterday it was one hour (always at the end of the afternoon).

Which queues does this regard? Are these the queues shown via this link? http://<server>:<port>/MessagingSystem/monitor/systemStatus.jsp

Sander

[Former Member]

Did your find the cause of that delay?

We have important delays in the same step.

[former_member431549]

What SP level are you on and what adapters are you using (file, jdbc, jms) ? Synch or asynch ?

This most likely means the adapter queue is operating on it's maximum number of concurrent messages.

In the url you show, it would probably be AFWCall, AFWRecv, AFWRqst and AFWSend, depending on sender/receiver and synch/asynch if you are using the typical technical adapters. This url should show you the bottleneck.

[Former Member]

16 + the latest patches framework core. We are using the file and jdbc adapter mostly asynch.

I'll keep checking the page today to see if the problem reappears, right now all queue sizes are zero.

[former_member431549]

I think below SP19 (or is it 20) the file adapter and jdbc adapter share one of those four queues if same direction and same asynch/synch type. Pretty sure they split in 19 or 20.

You can increase max threads on the queues. It's in visual admin, but I can't remember exact parm at the moment (one is 'max consumers', or something similar).

We ended up creating a de-central AE to move high volume/low priority messages separate from low volume/high priority messages. It's was just our way of dealing with our mix of messages.

[Former Member]

Thanks, SAP support just suggested me the same approach.

I am currently monitoring the queues to see if they are indeed the problem, but as always the patient is not ill anymore when the doctor is watching.

Sander