Posted: 27 Dec 2017 1:29 EST Last activity: 2 Jan 2018 9:33 EST
Resource Unavailable Exception : cause:Address already in use
In one of the application servers, we experienced the below issue. Later, we came to know that the port i.e.,application trying to use for making SOAP connection is already used by some other application/process. How, could we get to know, from which port Pega Application is trying to make a SOAP connection. will it try to make use of any default port defined or we define some where in our application.
Or these settings to defined at Server level independent of Pega Application. Could you please answer.
com.pega.pegarules.pub.services.ResourceUnavailableException: SOAP service failed, cause:Address already in use
To circumvent the issue, we restarted the App server.
Excuse me, if this seems more related to Server Infrastructure related question. I just want to know, are there any things defined at or controlled from Pega Application.
After restarting the application server, every thing works fine. There are no issues with external soap service, As it's working fine in Soap UI and in application too(post restart). The issue is, we are unable to figure out why the port used by application in making soap connection is already in use. Is it because, did we reach a max. no of connection s allowed. If so, is something defined at Pega application level. Please, let us know regarding this. Or It could be due to an issue at Server level.(But , after post restart of app server - everything works fine. Does it mean, Pega application entered some closed loop. As, we could see all the soap connections, it trying to make are in "CLOSED_WAIT". To circumvent the issue, we are restarting the app server. It means, all established connections made by application will be cleared and it's like a fresh start. Anyway, Thanks for your help. Karthik K
Please see : https://pdn.pega.com/support-articles/error-level-logging-soap-failure-responses
The invokeAxis2 activity is exposed - this allows you to revise the exception handling. The article above shows how to modify the Pega throw for "ResourceUnavailableException" so that it dumps the stack trace. As Pega utilizes the Axis API and attempts the connection from the JVM, this approach is needed to debug at that level.