cancel
Showing results for 
Search instead for 
Did you mean: 

AFW Receive Queue

former_member431549
Contributor
0 Kudos

We are running into a situation where we are hitting deadlocks on JDBC updates to an SQL Server database. We are going to address this problem separately, but it brings to light the potential for a problem occurring in one system to hang up the entire adapter engine.

We get 5 messages being delivered to this SQL Server database and then encounter deadlocks. These messages hang, showing status 'delivering' in MDT and nothing else goes through (appears to be a limit of 5 messages actively being delivered). Raising the limit would not be a good solution, as more would just hang.

Is there any way to set up queues by receiver for how messages get executed by the AFW ?

Thanks in advance.

Message was edited by: Tim Walker

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member431549
Contributor
0 Kudos

Found it. SAP Note 791655. Actually, this was the limit of 5 we found. Still looking for a way to queue by service.

Message was edited by: Tim Walker

former_member431549
Contributor
0 Kudos

We are still running into a problem in this area. I want to be able to control max concurrent messages per receiver service (end point business system) to prevent one type of itnerface from monopilizing all of the available queue entries. Any new ideas ?

Former Member
0 Kudos

Hi Tim,

>>Still looking for a way to queue by service.

If you want to queue messages to an end-point you could specify EOIO in your sender adapter (if it supports EOIO).

Thanks,

Jesse

former_member431549
Contributor
0 Kudos

They are already queued by AFW, and there is a max conccurrent total messages that can be active for the AFW. I want to be able to further limit concurrent messages by end point, so I don't believe EOIO will help, unless I make all of the interfaces EOIO, which I do not want to do.

former_member189324
Contributor
0 Kudos

Hi Tim,

XI30-SP13 allows access to external Database tables during mapping to use the JDBC adapters in the Integration Directory. Currently, the access is done using a direct JDBC connection. By using the JDBC adapter in mapping, you will no longer need to use the direct-connection

technique, or trying to get the connection pool to work.

This will alleviate the need for properties file, which will have to be maintained, to designate the server location in a fail-over situation.

Thanks

Prasad

former_member431549
Contributor
0 Kudos

Perhaps I was not clear before, but the SQL Server database is one of our end-points, not just a look-up during mapping. The message either starts via a JDBC select, or ends with a JDBC update/write.

And we are using JDBC not a direct connection using a .properties file.

former_member189324
Contributor
0 Kudos

If there is a limitation on Increasing the number of connections, i would suggest the connection pool functionality available in the j2ee engine