You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Grover Smith <Gr...@vocalocity.com> on 2009/02/10 21:10:40 UTC
Axis2 doesn't play nice with PFP (payflow, paypal)
This may be somewhat of an obscure issue, but we have discovered that
after making a PFP transaction (basically a creditcard processing API
call though paypal), our Axis2 based communication ceases to function
completely. Before making the PFP call, our Axis2 client can
successfully send soap requests and receive soap responses from a remote
server. After making a PFP API call, all future Axis2 soap requests
immediately receive a connection refused error. ngrep shows that packets
are no longer being sent to the remote soap server, but connection
refused exceptions are thrown from what appears to be the native http
socket connection. We have reproduced this on 2 different JVMs:
Jrockit jdk1.5.0_11
Sun jdk 1.5.0_17
The OS running the Axis2 client and making the PFP calls is Linux.
Once this state is entered, the only way to re-establish successful
Axis2 soap communication is to restart the appserver (jboss). This
almost seems like a system resource contention issue. However, making
Axis2 soap calls first does not break the PFP call. Any ideas as to
what might be happening or how to work around this issue would be
appreciated. A partial stack trace of the connection refused exception
follows.
Thanks,
Grover Smith
2009-01-29 19:09:00,843 [http-0.0.0.0-8080-10] INFO
[org.apache.commons.httpclient.HttpMethodDirector] I/O exception
(java.net.ConnectException) caught when processing request: Connection
refused
2009-01-29 19:09:00,843 [http-0.0.0.0-8080-10] INFO
[org.apache.commons.httpclient.HttpMethodDirector] Retrying request
2009-01-29 19:09:00,844 [http-0.0.0.0-8080-10] INFO
[org.apache.commons.httpclient.HttpMethodDirector] I/O exception
(java.net.ConnectException) caught when processing request: Connection
refused
2009-01-29 19:09:00,844 [http-0.0.0.0-8080-10] INFO
[org.apache.commons.httpclient.HttpMethodDirector] Retrying request
2009-01-29 19:09:00,844 [http-0.0.0.0-8080-10] INFO
[org.apache.commons.httpclient.HttpMethodDirector] I/O exception
(java.net.ConnectException) caught when processing request: Connection
refused
2009-01-29 19:09:00,844 [http-0.0.0.0-8080-10] INFO
[org.apache.commons.httpclient.HttpMethodDirector] Retrying request
2009-01-29 19:09:00,844 [http-0.0.0.0-8080-10] INFO
[org.apache.axis2.transport.http.HTTPSender] Unable to sendViaPost to
url[https://www.xyz.com/911form/wsdl/e911/soap_server2.php]
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:54
9)
at sun.reflect.GeneratedMethodAccessor1136.invoke(Unknown
Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSoc
ket(ReflectionSocketFactory.java:140)
at
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSo
cket(SSLProtocolSocketFactory.java:130)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:70
7)
at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCon
nectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMe
thodDirector.java:387)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMetho
dDirector.java:171)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
97)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
46)
at
org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(Abstrac
tHTTPSender.java:542)
at
org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:1
89)
at
org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageW
ithCommons(CommonsHTTPTransportSender.java:371)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(Common
sHTTPTransportSender.java:209)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOper
ation.java:401)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInA
xisOperation.java:228)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163
)
at
com._xyz.soap.wsdl.Address_ServiceStub.addEnterpriseRequest(Address_Serv
iceStub.java:686)
From: Grover Smith [mailto:Grover.Smith@vocalocity.com]
Sent: Tuesday, January 27, 2009 6:27 PM
To: axis-dev@ws.apache.org
Subject: Intermittent, automatic connection refused with no packets to
or from the server
Greetings All,
I am having some strange, intermittent connection refused problems with
the Axis2 client. I have used Axis2 1.4.1 to construct a java stub class
from a SOAP server WSDL. In a jboss server, I instantiate the stub and
use it to send requests to the SOAP server. This generally works fine,
but occasionally (as often as once a day), the Axis2 engine will begin
to throw Connection refused faults on every SOAP call. The strange
thing is, in this state ngrep shows zero packets to or from the SOAP
server. It seems clear that the connection refused faults are generated
without ever attempting to communicate with the SOAP server. At this
point, only redeploying the application will fix the issue. Even
instantiating a new stub will not allow communication to resume. Does
anyone have any ideas what might be happening and how it can be fixed?
If nothing else, is there a way to reinitialize the Axis engine without
redeploying?
This is the stub initialization code. It is also called when we want to
reinitialize the connection (such as when we detect a config change or
when we get into this state where communication is failing)
public void start() {
HttpTransportProperties.Authenticator authenticator = new
HttpTransportProperties.Authenticator();
authenticator.setPreemptiveAuthentication (true);
authenticator.setAuthSchemes(Arrays.asList(new
String[]{HttpTransportProperties.Authenticator.BASIC}));
authenticator.setUsername(BasicAuthUserName);
authenticator.setPassword(BasicAuthPassword);
TransportOutDescription tod = new
TransportOutDescription(org.apache.axis2.Constants.TRANSPORT_HTTPS);
CommonsHTTPTransportSender httpSender = new
CommonsHTTPTransportSender();
tod.setSender(httpSender);
if(null != stub) {
try {
stub._getServiceClient().getOptions().setProperty(HTTPConstants.AUTO_REL
EASE_CONNECTION, Boolean.TRUE);
stub._getServiceClient().getOptions().setCallTransportCleanup(true);
} catch (Throwable e) {
LOG.warn("error when trying to clean up old Axis stub",e);
}
}
try {
ConfigurationContext c =
ConfigurationContextFactory.createEmptyConfigurationContext();
c.setProperty("WSAddressingVersion",
"http://schemas.xmlsoap.org/ws/2004/08/addressing");
stub = new Address_ServiceStub(c, URL);
stub._getServiceClient().getOptions().setProperty(
HTTPConstants.AUTHENTICATE,authenticator);
stub._getServiceClient().getOptions().setProperty(org.apache.axis2.addre
ssing.AddressingConstants.WS_ADDRESSING_VERSION,org.apache.axis2.address
ing.AddressingConstants.Submission.WSA_NAMESPACE);
stub._getServiceClient().getOptions().setTransportOut(tod);
stub._getServiceClient().getOptions().setProperty(HTTPConstants.REUSE_HT
TP_CLIENT, Boolean.FALSE);
stub._getServiceClient().getOptions().setProperty(HTTPConstants.CACHED_H
TTP_CLIENT, Boolean.FALSE);
} catch (AxisFault e) {
LOG.error("start: Exception when setting up communication with xyz",
e);
}
}
This is a portion of the fault stack we are getting:
2009-01-27 22:31:37,264 [http-0.0.0.0-8080-10] ERROR [...] Exception
when attempting to communicate with xyx server.
org.apache.axis2.AxisFault: Connection refused
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at
org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:1
93)
at
org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageW
ithCommons(CommonsHTTPTransportSender.java:371)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(Common
sHTTPTransportSender.java:209)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:448)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOper
ation.java:401)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInA
xisOperation.java:228)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163
)
at
com._xyz.soap.wsdl.Address_ServiceStub.validateAddressRequest(Address_Se
rviceStub.java:2511)
Re: Axis2 doesn't play nice with PFP (payflow, paypal)
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Grover
> Before answering your questions, I will add a new development:
> yesterday we switched our soap communication method to use Axis 1.4
> (Axis 1) instead of Axis2 1.4.1. Making this change did resolve the
> issue and PFP does not break Axis 1 communication. At this point we
> are satisfied with this solution and have decided to move forward with
> Axis 1.
Thats good to hear!
>
> One other thing I should mention is that the soap server we are using
> Axis to communicate with requires basic authentication to connect, so
> simple telnet commands do get connection refused.
>
Hmm.. that should not happen, since a basic auth failure (which has a
HTTP response) is different from a connection refused - which means that
the remote host did not accept the message over the selected port.
>
> However, ngrep does show packets going to and from xyz.com when
> attempting the telnet connection, even when we are in the broken
> communication state.
>
I am not much familiar with ngrep.. but if communication takes place,
that means you have network level connectivity. What would be
interesting to see is the output of tcpdump for the manual telnet vs the
Axis2 connection attempt.. anyway, leave that to the next time you want
to revisit Axis2
cheers
asankha
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com
RE: Axis2 doesn't play nice with PFP (payflow, paypal)
Posted by Grover Smith <Gr...@vocalocity.com>.
Thank you for the response Asankha.
Before answering your questions, I will add a new development: yesterday
we switched our soap communication method to use Axis 1.4 (Axis 1)
instead of Axis2 1.4.1. Making this change did resolve the issue and
PFP does not break Axis 1 communication. At this point we are satisfied
with this solution and have decided to move forward with Axis 1.
Yes, the PFP software appears to make use of SSL socket factories. One
other thing I should mention is that the soap server we are using Axis
to communicate with requires basic authentication to connect, so simple
telnet commands do get connection refused. However, ngrep does show
packets going to and from xyz.com when attempting the telnet connection,
even when we are in the broken communication state.
Thanks again for taking time to consider our problem.
Grover Smith
From: Asankha Perera [mailto:asankha.apache@gmail.com] On Behalf Of
Asankha C. Perera
Sent: Wednesday, February 11, 2009 2:19 AM
To: axis-dev@ws.apache.org
Subject: Re: Axis2 doesn't play nice with PFP (payflow, paypal)
Hi Grover
Once this state is entered, the only way to re-establish successful
Axis2 soap communication is to restart the appserver (jboss). This
almost seems like a system resource contention issue. However, making
Axis2 soap calls first does not break the PFP call. Any ideas as to
what might be happening or how to work around this issue would be
appreciated.
What is the software making this 'PFP' call? is it doing something with
the SSL socket factories to your knowledge?
A partial stack trace of the connection refused exception follows.
....
2009-01-29 19:09:00,844 [http-0.0.0.0-8080-10] INFO
[org.apache.axis2.transport.http.HTTPSender] Unable to sendViaPost to
url[https://www.xyz.com/911form/wsdl/e911/soap_server2.php]
java.net.ConnectException: Connection refused
At this stage, from a command line on the same JBoss server, can you try
"telnet www.xyz.com 443" and see what happens?
cheers
asankha
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Axis2 doesn't play nice with PFP (payflow, paypal)
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Grover
> Once this state is entered, the only way to re-establish successful
> Axis2 soap communication is to restart the appserver (jboss). This
> almost seems like a system resource contention issue. However, making
> Axis2 soap calls first does not break the PFP call. Any ideas as to
> what might be happening or how to work around this issue would be
> appreciated.
What is the software making this 'PFP' call? is it doing something with
the SSL socket factories to your knowledge?
> A partial stack trace of the connection refused exception follows.
>
> ....
>
> 2009-01-29 19:09:00,844 [http-0.0.0.0-8080-10] INFO
> [org.apache.axis2.transport.http.HTTPSender] Unable to sendViaPost to
> url[https://www.xyz.com/911form/wsdl/e911/soap_server2.php]
>
> java.net.ConnectException: Connection refused
>
At this stage, from a command line on the same JBoss server, can you try
"telnet www.xyz.com 443" and see what happens?
cheers
asankha
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com