cancel
Showing results for 
Search instead for 
Did you mean: 

RFC_FAILURE affects Connection Pool

Former Member
0 Kudos

Using VB.NET (2003) with .Net Connector 2.0.

An intermittent problem causes a RFC Call to fail, and an exception is raised in the .NET code. The Exception message is:

See RFC trace file or SAP system log for more details

The Trace file shows:

        • ERROR file opened at 20051115 131423 GMT Standard

T, SAP-REL 640,0,78 RFC-VER 3 759904 MT-SL

<b>T:2844 Could not send rfc container 0x130

T:2844 <* RfcCall [1] : returns 1:RFC_FAILURE

T:2844 <* RfcCallReceive [1] : returns 1:RFC_FAILURE

>TS> Tue Nov 15 13:14:24 2005

T:2844 <* RfcCleanupContext [1] : returns

18:RFC_INVALID_HANDLE

T:2844 <* RfcCleanupContext [1] : returns

18:RFC_INVALID_HANDLE</b>

This error adversely affects the Connection Pool – as calls to other RFCs are now prone to similar intermittent errors…

Is there any way to prevent the problem causing problems with Connection Pool ?

Is there any way of removing a “faulty” connection from the pool ? (NB Close and Dispose on the connection does not help)

Accepted Solutions (0)

Answers (1)

Answers (1)

reiner_hille-doering
Active Contributor
0 Kudos

Thanks, this sounds interesting. I think I get the point, but perhaps you could isolate the problem to a code snipped. Where exactly does the exeption happen? I assume this is in a call after you took a connection from pool.

Wouldn't it help just to catch the exception and prevent that this connection to put back to pool? e.g.

proxy.Connection = Connection.GetConnectionFromPool(...)

Try

proxy.Method(...)

Catch e As RfcException

proxy.Connection.Close()

proxy.Connection = Nothing

End Catch

Finally

if proxy.Connection <> Nothing then

Connection.ReturnConnection(proxy.Connection)

end if

End Finally

(sorry if my VB is not correct)

Former Member
0 Kudos

The application is a Windows service - so I don't want to lose any connections. I assume that closing the connection (and not returning it) will affect the number of available connections in the pool(?).

I'm using async. RFC call, and the problem is detected in the callback function when the EndRFCCall is performed.

Original code:

Public Sub Execute_RFC(ByVal parameters as string())

...

' Assign SAP Connection to RFC Proxy

sapRFCProxy.Connection = SAPConnectionPool.GetConnectionFromPool(<i>ConnectString</i>)

Call the SAP RFC - Asynchronously

arAsyncResult = m_sapRFCProxy.BeginRFCCall( params..., AddressOf RFC_CallBack, objAsyncState)

End Sub

Private Sub RFC_CallBack(ByVal ar As IAsyncResult)

Try

' Retrieve the SAP RFC Response...

Call sapRFCProxy.EndRFCCall(ar, <i>param1, param2, etc...</i>)

Catch ex As Exception

' Log the Error...

End Try

' Return the Connection

Call SAPConnections.ReturnConnection(sapRFCProxy.Connection)

End Sub

I have changed the code as suggest so that the connection is closed, disposed but <u>not</u> returned. This cleared the RFC_INVALID_HANDLE errors, but the main problem of a corrupted connection persists.

Diagnostics produced by the amended code:

<u>Trace File (Info):</u>

2005-11-16 11:55:46Z Warning: RfcCleanupContext failed. Closing connection

<u>dev_RFC.trc</u>

      • ERROR file opened at 20051116 115546 GMT Standard T, SAP-REL 640,0,78 RFC-VER 3 759904 MT-SL

T:3068 ======> CPIC-CALL: 'CMSEND'

ERROR program state check for conversation 99610798

TIME Wed Nov 16 11:55:46 2005

RELEASE 640

COMPONENT CPIC (TCP/IP)

VERSION 3

RC 471

MODULE r3cpic.c

LINE 2576

DETAIL called function STSEND in state state=BUFFER_DATA2

COUNTER 1

T:3068 <* RfcCall [20] : returns 1:RFC_FAILURE

T:3068 <* RfcCallReceive [20] : returns 1:RFC_FAILURE

T:3068 <* RfcCleanupContext [20] : returns 1:RFC_FAILURE

Even with the change to the code, a call to a reliable RFC will now fail <u>intermittently</u> with:

T:2876 Could not send rfc container 0x130

T:2876 <* RfcCall [24] : returns 1:RFC_FAILURE

T:2876 <* RfcCallReceive [24] : returns 1:RFC_FAILURE

Thanks

reiner_hille-doering
Active Contributor
0 Kudos

I cannot tell you why the connection is lost sometime. Maybe you have a network problem. Anyway, with this workarround you wouldn't fill the connection pool with bad connections.

reiner_hille-doering
Active Contributor
0 Kudos

Another possible reason could be that the connection timeout of the Gateway (server side) is shorter than the idle-timeout of the connection pool (client side). You could try to lower it. See SAP.Connector.Config class documentation for details.

Former Member
0 Kudos

Thanks, I'll look into this...

Former Member
0 Kudos

I set the Client Side idle timeout in the app. config file:

MaxIdleTime="15"

This was originally set to 60.

Alas, this made no difference and we still have the same problem (and is still being investigated)...

The server Profile parameters are the SAP default ie

gq/cpic_timeout 20

gw/gwwp_connect_timeout 20

gw/auto_disconnect 0

I assume these are the main server parameters that would affect this test.

Thanks

reiner_hille-doering
Active Contributor
0 Kudos

You may turn on RFC trace on both, client and server side. I'm sure you will see "auto close" after the idle time, either on server or client side.

Former Member
0 Kudos

Latest Trace below (FYI)

We are trying to identify the base cause of this problem-then we may be able to address the .NET issue

>>>> [2] <unknown> : EXT <ac: 466> L pat1011.europe.shell.com >>> FLUSH (READ) (14881986)

-{7BA862ED-FAC3-4FE9-B34E-8097C2BAC41B}

>TS> Tue Nov 29 13:59:07 2005

Send RFCHEADER: 01/LIT/IEEE/SPACE-U2/4102

Send UNICODE-RFCHEADER: cp:4102/ce:IGNORE/te:REJECT/cs:2/rc:0x00000023

UUID: send_rfcuuid {7BA862ED-FAC3-4FE9-B34E-8097C2BAC41B}

>TS> Tue Nov 29 13:59:08 2005

Could not send rfc container 0x130

RFC ERROR > ab_rfcput_utf8_tring [2]>TS> Tue Nov 29 13:59:09 2005

Converter returned 512

Cannot convert from codepage 4102 to codepage 4102 Value of ignore flag is: 1

>TS> Tue Nov 29 13:59:10 2005

Hex value of repl_char is: 0x23

Hex value of g_rfc_repl_char is: 0x23

Size of output area is: 80

>TS> Tue Nov 29 13:59:11 2005

Char stream length is: 40

The hex-charakter stream is:

000000 | D087DB06 B8F3ED06 FFFFFFFF FFFFFFFF |................|

000010 | FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|

000020 | FFFFFFFF FFFFFFFF 00000000 00000000 |................|

>>>> [2] <unknown> : EXT <ac: 469> L pat1011.xxx.xxx.com >>> CLOSE abrfc.c 790 (14881986)

-{7BA862ED-FAC3-4FE9-B34E-8097C2BAC41B}

>TS> Tue Nov 29 13:59:15 2005

<* RfcCall [2] : returns 1:RFC_FAILURE

>TS> Tue Nov 29 13:59:16 2005

<* RfcCallReceive [2] : returns 1:RFC_FAILURE

>>>>RfcLastErrorEx

>>>> [2] <unknown> : EXT <ac: 473> L pat1011.xxx.xxx.com >>> FREE abrfcio.c 3427 (14881986)

-{7BA862ED-FAC3-4FE9-B34E-8097C2BAC41B}

        • Trace file opened at 20051129 135917 GMT Standard T, SAP-REL 640,0,78 RFC-VER 3 759904 MT-SL

<* RfcLastErrorEx *>

*> RfcClose called by external program ...

>TS> Tue Nov 29 13:59:18 2005

handle = 2

*> rfcClose called by RFC-Library in file: abrfc.c, line: 532

handle = 2

        • Trace file opened at 20051129 135919 GMT Standard T, SAP-REL 640,0,78 RFC-VER 3 759904 MT-SL

<* rfcClose

>* RfcClose

reiner_hille-doering
Active Contributor
0 Kudos

Please open a SAP Support ticket (OSS) with the description and trace files on component BC-OP-NET-NCO. You may also refer to this forum topic.

Former Member
0 Kudos

Upgraded librfc32.dll:

From version: 6403.3.78.4732

To 6404.4.99.4873 (supplied by support)

This has resolved the main issue.

(but has introduced a another different problem! - not for this thread)