cancel
Showing results for 
Search instead for 
Did you mean: 

JCO connections hanged in SMGW transaction at SAP

0 Kudos

Hi ,

I have deployed an ear application in SAP WAS 7.0 which basically talks to my SAP backend using JCO 2.1 connectors. The application will fetch the data from SAP backend calling FM using JCO 2.1.

I m using JCO pool manager and set to default 100 connections and taken care of release connections after every RFC call in finally block. The connections released successfully in Dev and QA landscapes. In prod environment of customer, we are facing connections hang issues when it reaches to peak state of 100. It is due to max conversations reached at SAP backend, but the connections should eventually drop in SMGW which is not happening. There are some lost connections got hanged and remains for days and even they are not re-used. When i run method to release the pool, all connections are focibly returned back to pool, but lost connections still remain there.

Can somebody has similar situation ?

if connections reached to max in SMGW, will the connections from external client applications will get hanged ?

Does the JCO have control on the hanged connections if it reaches to max number?

Any help is appreciated!!!

Regards,

Ravi.

Accepted Solutions (0)

Answers (3)

Answers (3)

0 Kudos

Hi ,

Thanks for the SAP Notes, i have already checked these notes before i post. when converstions reached to max number for example 100, the web application deployed in SAP WAS doesn't get any new connection and even the connections are not decreasing in SMGW. I just want to check during this situation does SAP WAS or web application has control on the connections ?

Regards,

Ravi.

dao_ha
Active Contributor
0 Kudos

Hi Ravi,

I believe when the max. no of connections allowed is reached in the backend system, of course, no new connection can be established. Not sure if the WAS or the web app can do anything here. You're right, the hung connections seen in SMGW should be dropped eventually; these are controlled by a combination of gw/*_timeout parameters of the backend instance profile. So, you might want to take a look at these parameters and adjust them accordingly. Obviously, in your PROD environment, the backend needs to handle a lot more connections (besides your app's JCos). As per the relevant SAP Notes, you might want to increase the number of CPIC connections allowed (on the backend).

Regards,

Dao

0 Kudos

HI ,

Thanks , I could get some more inputs from customer and came to know that they are running on windows X64bit OS and SAP Java application using JCO 2.18.

I referred to one of the popular site, it says clearly that JCO 2.1.8 doesn't support windows X64 bit OS.

"SAP JCo Version 2.1.8 is not supported on the Windows 64-bit platform. The JCo API does not support this platform"

http://download.oracle.com/docs/cd/E15523_01/doc.1111/e17054/intro.htm (Reference URL)

Could some body help me out whether the above statement is true or false? If it is true, Could you please provide any SAP notes related to this statement?

do you think the later version 2.1.9 support windows x64 bit OS successfully ?

Appreciate your help !!!

Regards,

Ravi.

Former Member
0 Kudos

The relevant SAP note here is [549268|https://service.sap.com/sap/support/notes/549268].

But in this context there is big difference between the terms "not supported" and "does not work".

When SAP speaks of "not supported" this means that there won't be any SAP support for this configuration but this does not say anything about if this works technically. "Not supported" is more a legal issue than a technical one. SAP did not test this configuration and therefore also cannot guarantee to work.

Regarding JCo 2.1 I can say that technically it works with all Windows 32- and 64-bit versions. In contrast to that it really does not work with JRE releases >= 1.5 when using BCD types (type P) within your function modules.

From my point of view the connection issues don't have anything to do with the Windows version here.

And it is still not clear to me, if the maximum number of CPIC connections is reached at the AS ABAP/gateway side or the Java side. Furthermore it is not clear if these "hanging connections" were opened with your application at all or if they belong to another application.

dao_ha
Active Contributor
0 Kudos

Hi Ravi,

I have to agree with what Stefan said; in your case, the JCO connections were WORKING until they reached the max. no. of connections so it's not a question of compatibility here

Regards,

Dao

0 Kudos

HI Doa/Stefan,

I too agree with both of your comments and SAP Notes really helped to come out of that direction. We are planning to have customer sessions in couple of days, i would analyze the logs and come out whether issue is with loadbalancing or JCO 2.1.8 is behaving differently in cluster environment.

Regards,

Ravi.

0 Kudos

Hi,

The issues are not with load balancing or with JCO 2.1.8, one of the external RFC connection from java applicaiton is not releasing properly and hanged in SMGW. We have provided function to explicitly call release connection pool but still these connections are not releasing. One important observation we had is , we are not able to release these connections manulally even from SMGW using Goto->Active Connections->Delete.Once we manually delete these connection, we have SAP error code as 474 and remains these hanged connection until we restart SAP server.

1) Could some body help me out how we can manually delete the inactive connections or lost reference connections from SMGW?

Regards,

Ravi.

dao_ha
Active Contributor
0 Kudos

Hi Ravi,

Please check SAP Note 1095272 to see if it's applicable (the third cause). I think the Delete in SMGW (where you went) only apply to active connections. You'd probably want to check out SAP Help for using the 'gwmon' program at the OS level, if needed.

Regards,

Dao

dao_ha
Active Contributor
0 Kudos

Hi Ravi,

Please check the default trace to see which host (WAS or backend) got the error of "max. no. of 100 conversations exceeded" then see SAP note #316877.

Hope it helps.

Regards,

Dao

Former Member
0 Kudos

check this out!!