+ Start a Discussion
JohnBarnesJohnBarnes 

Socket Level connection timeout after 1 minute

We are having a strange issue with an integration we are writing around socket level timeouts. This is happening usually within a minute of the application running and doesn't appear to be a session management issue. This is happening while doing a series (sometimes as few as 70) of small SOQL queries (each returns one row) that happens at the beginning of the application.

We are seeing this exception:

java.net.ConnectException: Connection timed out: connect
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.net.ConnectException: Connection timed out: connect
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)

This is using JDK1.5.0_01 and Axis 1.2.1. and going against a trial version account that was upgraded to EE

Has anyone seen this or have any ideas of what may be causing the issue? Since itis an Axis/Java exception we are going to try various combinations of JVM's and Axis levels to see if that resolves it.

Any ideas or thoughts would be appreciated!

Thanks,

John
thedgethedge
We just started to get something very similar to your error message. Things were working fine with this integration until the middle to end of lastweek. The integration runs for just a moment or so and then terminates.

We are using:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-b05)
Axis 1.2

Error:
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.useception
faultSubcode:
faultString: java.net.SocketException: Connection reset
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:java.net.SocketExcept
: Connection reset
adamgadamg
Are you noticing more socket resets since this weekend, or have these been happening for a while?

FWIW, I've heard some reports that Axis 1.3 does a better job with socket resets, but I'm still eager to see if there is something that can be improved on our side.
JohnBarnesJohnBarnes
We have been noticing it for awhile (previous to this weekend's maintenance) - The last 2-3 weeks to be exact.
brianb08brianb08
Looking through the boards today, this appears to be a recent issue affecting many people. I am using axis 1.3 (the gzip compression really improves things!), and using the commons HTTP client, but still have issues.

The code has appropriate exception handling and attempts to work through the problem, but sometimes there are just too many resets to get through it.
-Brian
JohnBarnesJohnBarnes
Brian,

I'm sorry to hear you are having the same problem. We are going to try Axis 1.3 and Gzip but it sounds like that may not totally resolve the issue. How long have you been seeing the issue?

- John
brianb08brianb08
Seems to have started towards end of last week, but I'm not certain. I didn't get into debugging things here until Monday. We've put in a support ticket that is 'escalated' to api support, with 48 hour response :(

I've been using axis 1.3 for a few weeks now and it was working well. I hadn't turned on the compression until last night (hoping that the compression would reduce download times lowering probability of timeout).

I'll definitely leave the compression on... it makes some operations 5x faster.
JohnBarnesJohnBarnes
We have narrowed it down in our case to the SOQL queries. It happens during a series of simple queries that retrieve the SFDC ID based on the back-end system ID. The queries seem simple simple on the surface (Select ID where Site = 'X') but we confirmed that the field they are using for the back-end key is not indexed so we are waiting on support to add an index to see if that resolves the issue.

We aren't seeing this issue with any of the updates or inserts. Perhaps we will try Axis 1.3 and turn on the compression to see if that helps out as well, but the latency is probably on the SFDC end in this case and not in the transport.
SuperfellSuperfell
You can also up the timeout setting in Axis from its 1 minute default, see the setTimeout call.
brianb08brianb08
I've tried setting timeout from various values between 1 min and 1 hour. The only thing having it set to one hour did was delay the timeout exception from occurring for 1 hour. It still happens.

The query I'm using is SELECT {field_list} from {table}. (Where field_list and table are set based on object descriptions). This code had been running for several weeks without these types of issues.
-Brian
Rick.BanisterRick.Banister
If this is still an issue, I can help you. My company sells a database integration product, Relational Junction for Salesforce, that allows 2-way synchronization between your Salesforce org and a local database (Oracle, SQLServer, MySQL, or Sybase). We have extensive retry logic and tight control of timeout parameters. I really enjoy when we get timed out or disconnected in a demo because Relational Junction automatically reconects (and doesn't give up reconnecting for 20 minutes!) and restarts where it left off.

You can contact me directly at Rick.Banister@sesamesoftware.com or visit http://www.sesamesoftware.com to download documentation or request a product demo. This is a very pain-free and automated product which could have you a replication warehouse in minutes with no design work.
Amine HAmine H
i resolved this by developing a retry logic job in my etl, i keep retrying the connection until it gets successful.
here is an how to http://talendexpert.com/talend-salesforce-retry-logic-job/