search

johvargas / sfdc-wsc

Automatically exported from code.google.com/p/sfdc-wsc
0 stars 0 forks source link

Failed to get next elementcom.sforce.ws.ConnectionException #11

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. call Connector.newConnection(user, password)

What is the expected output? What do you see instead?
I would expect to get an EnterpriseConnection.  Instead, I get the
following stack trace:

Failed to get next elementcom.sforce.ws.ConnectionException: Failed to get
next element
at com.sforce.ws.parser.XmlInputStream.nextTag(XmlInputStream.java:168)
    at
com.sforce.ws.transport.SoapConnection.readSoapEnvelopeStart(SoapConnection.java
:230)
    at
com.sforce.ws.transport.SoapConnection.createException(SoapConnection.java:163)
    at com.sforce.ws.transport.SoapConnection.receive(SoapConnection.java:133)
    at com.sforce.ws.transport.SoapConnection.send(SoapConnection.java:106)
    at
com.sforce.soap.enterprise.EnterpriseConnection.login(EnterpriseConnection.java:
1)
    at
com.sforce.soap.enterprise.EnterpriseConnection.<init>(EnterpriseConnection.java
:1)
    at com.sforce.soap.enterprise.Connector.newConnection(Connector.java:1)
    at com.sforce.soap.enterprise.Connector.newConnection(Connector.java:1)
    at helloworld.testServlet.doGet(testServlet.java:94)

What version of the product are you using? On what operating system?
I'm using wsc-gae-16_0.jar and the Enterprise library (not partner)

Please provide any additional information below.

Original issue reported on code.google.com by tynia.y...@gmail.com on 4 Dec 2009 at 4:29

GoogleCodeExporter commented 8 years ago 
This happens when the version of the stub does not match the endpoint version. 
Make
sure you are setting the 16.0, enterprise endpoint.

It is also good to see the XML. set ConnectorConfig.setTrace(true), to display 
the
xml request/response.

Original comment by manoj.ch...@gmail.com on 4 Dec 2009 at 4:44

GoogleCodeExporter commented 8 years ago 
I just regenerated my Java library for my WSDL, and Connector.END_POINT still 
points
to "https://www.salesforce.com/services/Soap/c/15.0";

Any suggestions?

Original comment by tynia.y...@gmail.com on 4 Dec 2009 at 5:10

GoogleCodeExporter commented 8 years ago 
Endpoint is taken from the wsdl. So you are using 15.0 wsdl. It should be ok. 
See
what xml the server returns.

Original comment by manoj.ch...@gmail.com on 4 Dec 2009 at 5:44

GoogleCodeExporter commented 8 years ago 
XML:
<?xml version="1.0" encoding="UTF-8"?><env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><env:Body><m:login
xmlns:m="urn:enterprise.soap.sforce.com"
xmlns:sobj="urn:sobject.enterprise.soap.sforce.com"><m:username>MY_EMAIL</m:user
name><m:password>MY_PASSWORD</m:password></m:login></env:Body></env:Envelope>

Original comment by tynia.y...@gmail.com on 4 Dec 2009 at 6:04

GoogleCodeExporter commented 8 years ago 
I think that's the XML that I'm sending.  It throws the ConnectionException 
before I
can see any response.  Am I missing something here?

Original comment by tynia.y...@gmail.com on 4 Dec 2009 at 6:40

GoogleCodeExporter commented 8 years ago 
Ya, it looks like the server is not sending an xml response back. Is there any 
proxy
setting you have to do on the google app engine?

BTW, are running from google app engine? If not you should not use the
wsc-gae-16_0.jar. There is a different jar for running in normal jdk.

Original comment by manoj.ch...@gmail.com on 4 Dec 2009 at 6:49

GoogleCodeExporter commented 8 years ago 
I'm running from GAE.  It works sometimes, and has been working (mostly) for a 
few
months now.  Lately though, it's been working less frequently.

Original comment by tynia.y...@gmail.com on 4 Dec 2009 at 1:08

GoogleCodeExporter commented 8 years ago 
This is at the very bottom of the stack trace:
com.sforce.ws.parser.XmlPullParserException: only whitespace content allowed 
before
start tag and not T (position: START_DOCUMENT seen T... @1:1) at
com.sforce.ws.parser.MXParser.parseProlog(MXParser.java:1468) at
com.sforce.ws.parser.MXParser.nextImpl(MXParser.java:1345) at
com.sforce.ws.parser.MXParser.next(MXParser.java:1049) at
com.sforce.ws.parser.MXParser.nextTag(MXParser.java:1035) at
com.sforce.ws.parser.XmlInputStream.nextTag(XmlInputStream.java:166) ... 49 
more done

Original comment by tynia.y...@gmail.com on 4 Dec 2009 at 1:13

GoogleCodeExporter commented 8 years ago 
I also see this in my GAE logs: 
com.sforce.ws.transport.GAEHttpTransport getContent: getContent: Timeout while
fetching: https://www.salesforce.com/services/Soap/c/15.0

Original comment by tynia.y...@gmail.com on 4 Dec 2009 at 1:27

GoogleCodeExporter commented 8 years ago 
Ok, that means google proxy server is timing out your request and sending back 
a non
xml response. Nothing wrong with WSC. Not sure what you can do about the 
timeout.

Original comment by manoj.ch...@gmail.com on 4 Dec 2009 at 4:09

GoogleCodeExporter commented 8 years ago 
Should it even come close to timing out when trying to make a connection 
though?  I'd
understand if it was for a query (and I suspect that particular error is 
related to a
query I was trying to run) but the following stack trace is what I see 
(sometimes)
when I try to just get an EnterpriseConnection.

Failed to get next elementcom.sforce.ws.ConnectionException: Failed to get next 
element
    at com.sforce.ws.parser.XmlInputStream.nextTag(XmlInputStream.java:168)
    at com.sforce.ws.transport.SoapConnection.readSoapEnvelopeStart(SoapConnection.java:230)
    at com.sforce.ws.transport.SoapConnection.createException(SoapConnection.java:163)
    at com.sforce.ws.transport.SoapConnection.receive(SoapConnection.java:133)
    at com.sforce.ws.transport.SoapConnection.send(SoapConnection.java:106)
    at com.sforce.soap.enterprise.EnterpriseConnection.login(EnterpriseConnection.java:1)
    at com.sforce.soap.enterprise.EnterpriseConnection.<init>(EnterpriseConnection.java:1)
    at com.sforce.soap.enterprise.Connector.newConnection(Connector.java:1)
    at com.sforce.soap.enterprise.Connector.newConnection(Connector.java:1)
    at helloworld.testServlet.doGet(testServlet.java:100)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
    at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
a:1093)
    at
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(Transactio
nCleanupFilter.java:43)
    at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
a:1084)
    at
com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilte
r.java:121)
    at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
a:1084)
    at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
    at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
    at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
    at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
    at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
    at
com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineW
ebAppContext.java:54)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
    at
com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.han
dle(JettyContainerService.java:313)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
    at org.mortbay.jetty.Server.handle(Server.java:313)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
    at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.ja
va:830)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
    at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: com.sforce.ws.parser.XmlPullParserException: only whitespace content
allowed before start tag and not T (position: START_DOCUMENT seen T... @1:1) 
    at com.sforce.ws.parser.MXParser.parseProlog(MXParser.java:1468)
    at com.sforce.ws.parser.MXParser.nextImpl(MXParser.java:1345)
    at com.sforce.ws.parser.MXParser.next(MXParser.java:1049)
    at com.sforce.ws.parser.MXParser.nextTag(MXParser.java:1035)
    at com.sforce.ws.parser.XmlInputStream.nextTag(XmlInputStream.java:166)
    ... 34 more

Original comment by tynia.y...@gmail.com on 4 Dec 2009 at 4:36

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I don't mean to be a pain, but I really don't think this is a GAE issue.  The
following code isn't doing anything that (from my end) should take a long time. 
Definitely not long enough to timeout on GAE:

EnterpriseConnection connection = Connector.newConnection(user, password);

Based on the documentation, this is how to connect to SFDC.  I'm not running any
queries, or doing anything fancy.  Just connecting to Salesforce.

But non-deterministically, I get the ConnectionException that says it failed to 
get
the next element.  

I looked into the circumstances around Comment 9, and that is a separate issue. 
 That
seems to occur when I run a query in SFDC.  I can understand how that might 
time out.
 I do not see how the ConnectionException is related though.

Stack Trace:
Failed to get next elementcom.sforce.ws.ConnectionException: Failed to get next 
element
    at com.sforce.ws.parser.XmlInputStream.nextTag(Unknown Source)
    at com.sforce.ws.transport.SoapConnection.readSoapEnvelopeStart(Unknown 
Source)
    at com.sforce.ws.transport.SoapConnection.createException(Unknown Source)
    at com.sforce.ws.transport.SoapConnection.receive(Unknown Source)
    at com.sforce.ws.transport.SoapConnection.send(Unknown Source)
    at 
com.sforce.soap.enterprise.EnterpriseConnection.login(EnterpriseConnection.java:
1)
    at 
com.sforce.soap.enterprise.EnterpriseConnection.<init>(EnterpriseConnection.java
:1)
    at com.sforce.soap.enterprise.Connector.newConnection(Connector.java:1)
    at com.sforce.soap.enterprise.Connector.newConnection(Connector.java:1)
    at helloworld.testServlet.doGet(testServlet.java:100)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
    at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
a:109
3)
    at
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(Transactio
nClea
nupFilter.java:43)
    at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
a:108
4)
    at
com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilte
r.jav
a:121)
    at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
a:108
4)
    at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
    at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
    at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
    at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
    at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
    at
com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineW
ebApp
Context.java:54)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
    at
com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.han
dle(J
ettyContainerService.java:313)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
    at org.mortbay.jetty.Server.handle(Server.java:313)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
    at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.ja
va:83
0)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
    at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
    at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: com.sforce.ws.parser.XmlPullParserException: only whitespace content
allowed before start tag and not T (position: START_DOCUMENT seen T... @1:1) 
    at com.sforce.ws.parser.MXParser.parseProlog(Unknown Source)
    at com.sforce.ws.parser.MXParser.nextImpl(Unknown Source)
    at com.sforce.ws.parser.MXParser.next(Unknown Source)
    at com.sforce.ws.parser.MXParser.nextTag(Unknown Source)
    ... 35 more

Original comment by tynia.y...@gmail.com on 5 Dec 2009 at 5:30

GoogleCodeExporter commented 8 years ago 
When you call Connector.newConnection(), it does a login call to salesforce. 
Which is
failing because the server or google-proxy is returning a non xml response. WSC 
is
trying to parse this and failing.

Original comment by manoj.ch...@gmail.com on 6 Dec 2009 at 12:51

GoogleCodeExporter commented 8 years ago 
Thanks for the response.  Is there something I can change about my GAE setup 
that will 
help?  Or has someone notified the GAE team if this is something they need to 
fix?

Given that this library is supposed to work with GAE specifically, the 
inability to 
connect to SFDC from GAE makes this library slightly less useful...

Everything was working fine until a week ago.  Nothing has changed on my end, 
but I'm 
wondering if something changed?

Original comment by tynia.y...@gmail.com on 7 Dec 2009 at 3:46

GoogleCodeExporter commented 8 years ago 
This has been a recurring issue with Google wave Robots that are trying to 
connect to 
Salesforce using the same GAE jars. Appengine has a limit of 30 seconds for a 
http 
request and it times out if the response does not return in 30 seconds.

The following is from the appengine documentation:

 http://code.google.com/appengine/docs/whatisgoogleappengine.html

On this page:

Under Secure Sandbox: 

    "Application code only runs in response to a web request, a queued task, or a 
scheduled task, and must return response data within 30 seconds in any case. A 
request handler cannot spawn a sub-process or execute code after the response 
has 
been sent."

It looks like the request to connect to Salesforce is using taking longer than 
30 
seconds and it is causing all sorts of issues. I could not find a way to 
increase the 
timeout in Appengine and I believe, Google does not allow it to be more than 30 
seconds.

Salesforce needs to speed up the connection process so that it can be done 
under 30 
seconds.

Original comment by venkat.p...@gmail.com on 7 Dec 2009 at 9:00

GoogleCodeExporter commented 8 years ago 
So...how do we get Salesforce to speed up the connection process?

Original comment by tynia.y...@gmail.com on 8 Dec 2009 at 2:18

GoogleCodeExporter commented 8 years ago 
Try connecting to salesforce directly (not from google app engine) and see if 
it is
taking longer than 30sec to login.

Original comment by manoj.ch...@gmail.com on 8 Dec 2009 at 3:51

GoogleCodeExporter commented 8 years ago 
Hi Manoj,

I have been experiencing the same exact behavior as cited by Tynia.  
Connectivity
between GAE and sfdc was extremely reliable for a few months.  Within the last 2
weeks I've seen connection failures occurring more often than successes.  I 
have not
changed my code or upgraded the GAE version (1.2.6) in that time.

I'm seeing this behavior with the development (local sandbox) version of GAE 
and less
so with my deployed app.

In my case, the login is timing out well before the 30 second GAE limit.  Here 
is a
snippet from my trace which shows that the 30 second limit is not reached.  My 
code
even  catches the first exception and tries again to make the connection.  Both 
tries
fail within 5 seconds.

Authentication endpoint https://www.salesforce.com/services/Soap/u/16.0
Dec 8, 2009 7:49:38 PM com.sforce.ws.transport.GAEHttpTransport getContent
INFO: <?xml version="1.0" encoding="UTF-8"?><env:Envelope
   xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001
/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <env:Body>
  <m:login xmlns:m="urn:partner.soap.sforce.com"
xmlns:sobj="urn:sobject.partner.soap.sfor
ce.com">
   <m:username>MY_NAME</m:username>
   <m:password>MY_PASSWORD</m:password>
  </m:login>
 </env:Body>
</env:Envelope>
Dec 8, 2009 7:49:43 PM com.sforce.ws.transport.GAEHttpTransport getContent
WARNING: getContent: Timeout while fetching:
https://www.salesforce.com/services/Soap/u/16
.0
PartnerConnection error Failed to get next element trying again
Dec 8, 2009 7:49:43 PM com.sforce.ws.transport.GAEHttpTransport getContent
INFO: <?xml version="1.0" encoding="UTF-8"?><env:Envelope
   xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001
/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <env:Body>
  <m:login xmlns:m="urn:partner.soap.sforce.com"
xmlns:sobj="urn:sobject.partner.soap.sfor
ce.com">
   <m:username>MY_NAME</m:username>
   <m:password>MY_PASSWORD</m:password>
  </m:login>
 </env:Body>
</env:Envelope>
Dec 8, 2009 7:49:48 PM com.sforce.ws.transport.GAEHttpTransport getContent
WARNING: getContent: Timeout while fetching:
https://www.salesforce.com/services/Soap/u/16
.0

I view not being able to reliably logon to sfdc from GAE as a Critical Issue.  
Please
let me know if I can assist in getting this resolved.

David

Original comment by turntwo...@gmail.com on 8 Dec 2009 at 8:32

GoogleCodeExporter commented 8 years ago 
There isnt much I can do from salesforce side. The request is timing out at the 
google 
app engine. Is there a way to set timeout on app engine? GAEHttpTransport.java 
is the 
class which use URLFetchService.

Original comment by manoj.ch...@gmail.com on 8 Dec 2009 at 9:59

GoogleCodeExporter commented 8 years ago 
To my knowledge, there have been many requests to increase the timeout on GAE 
but it 
isn't possible.

David and I both used to be able to sign into SFDC successfully, but are now 
experiencing more failures than successes.  The timeout on App Engine has not 
changed, 
so the logical conclusion seems to be that SFDC is taking longer to connect.

Original comment by tynia.y...@gmail.com on 8 Dec 2009 at 10:03

GoogleCodeExporter commented 8 years ago 
You could try to connect outside of app engine and see if it is taking longer to
connect to sfdc.

You can also contact sfdc support. They will be able to trace your call and 
find out
whether the call is reaching sfdc and timing out.

You could check the login history in your org. See if the calls are reaching 
sfdc.

Original comment by manoj.ch...@gmail.com on 8 Dec 2009 at 10:25

GoogleCodeExporter commented 8 years ago 
I confirmed that in the GAE documentation the default timeout for the local 
case is 5
seconds:

http://code.google.com/appengine/docs/java/urlfetch/overview.html#Requests

However this can be set up to 10 seconds.  

I've gotten the source from the sfdc-wsc repository and GAEHttpTransport is not 
there.

Manoj, can you shed some light on this?

Allowing the GAEHttpTransport to change the URLFetch timeout to 10 seconds 
should
alleviate the problems were experiencing.

However, the performance of sfdc has degraded over the last 2 weeks and I will 
also
follow your suggestion to contact sfdc support.

Original comment by turntwo...@gmail.com on 8 Dec 2009 at 10:54

GoogleCodeExporter commented 8 years ago 
It is in a different branch:

http://code.google.com/p/sfdc-
wsc/source/browse/branches/gae/java/src/com/sforce/ws/transport/GAEHttpTransport
.java

Original comment by manoj.ch...@gmail.com on 8 Dec 2009 at 10:59

GoogleCodeExporter commented 8 years ago 
I just tried connecting to SFDC outside of App Engine.  The connection times 
vary 
pretty significantly.  

I made 2 sets of 10 successive calls to Connector.newConnection(user, password).

From the first set of 10 calls, 6 took 1 second or less, while 4 took 5.4 
seconds.

From the second set of 10 calls, only 2 attempts took less than a second, while 
the 
remaining 8 calls took 5.5 or 6.2 seconds.

There doesn't seem to be any pattern, except that most of the calls to SFDC 
took more 
than the time allotted by GAE.

Original comment by tynia.y...@gmail.com on 9 Dec 2009 at 5:19

GoogleCodeExporter commented 8 years ago 
Hi Manoj,

Can you change the GAEHttpTransport to increase the timeout to 10 seconds?  
This would 
help, since most of my calls to SFDC to connect took longer than 5 seconds.

Original comment by tynia.y...@gmail.com on 10 Dec 2009 at 6:22

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Here is the code that needs to be changed:

   public OutputStream connect(String uri, String soapAction) throws IOException {

        // log.info( uri );   log.info( soapAction );

        url = new URL(uri);

        //log.warning("setting deadline to 10seconds");
        request = new HTTPRequest(url,HTTPMethod.POST,
                                      FetchOptions.Builder.withDeadline(10D));

        if (soapAction == null) {   soapAction = ""; }

        request.addHeader( new HTTPHeader("Content-Type", "text/xml; charset=UTF-8") 
);
        request.addHeader( new HTTPHeader("Accept", "text/xml") );
        request.addHeader( new HTTPHeader("User-Agent", VersionInfo.info()) );
        request.addHeader( new HTTPHeader("SOAPAction", "\"" + soapAction + "\"") );

        output = new ByteArrayOutputStream();
        return output;
    }

After increasing the deadline to 10 seconds, it started working for me. Also, 
you 
might want to add the following line to your appengine-web.xml to enable 
precompilation (for the latest sdk though).

    <precompilation-enabled>true</precompilation-enabled>

Original comment by venkat.p...@gmail.com on 10 Dec 2009 at 7:33

GoogleCodeExporter commented 8 years ago 
Hi Venkat,

I made the same code change and built locally.  When I tested this against the 
local
developer sandbox it did not seem to honor the 10 second timeout -- I still got
timeouts after 5 seconds.  I did not try uploading the code to GAE.  

Did you see the 10 second timeout being honored both locally and also when 
uploaded
to GAE?

David

Original comment by turntwo...@gmail.com on 10 Dec 2009 at 8:50

GoogleCodeExporter commented 8 years ago 
It does not work on the Sandbox (local box). Try uploading your code to the GAE.

Venkat Polisetti

Original comment by venkat.p...@gmail.com on 10 Dec 2009 at 8:57

GoogleCodeExporter commented 8 years ago 
Hi Venkat,  Thanks for the code fix.  I built locally and uploaded to GAE, and 
I'm 
able to successfully connect.  Manoj, you might want to incorporate the fix 
into your 
library.

I now have a similar but separate issue, which is that when I run a query, it 
sometimes times out.  Not always, but sometimes.  I found this thread, which I 
think 
is related.  The guy describes a very similar situation: 
http://community.salesforce.com/sforce/board/message?
board.id=JAVA_development&message.id=7009

Is anyone else seeing this?  Does SFDC just randomly decide to take a long time 
with 
some of their requests?

Original comment by tynia.y...@gmail.com on 11 Dec 2009 at 5:45

GoogleCodeExporter commented 8 years ago 
I have not seen that for me so far but it could happen to us at any time. The 
real 
issue is with GAE limiting urlFetch time to 10 sec max. If you have a ton of 
data in 
SF and trying to get a few rows, some times will take more than 10 secs. I have 
seen 
that happen in Oracle which is used by SF to store our data behind the scenes 
(how 
do I know this, from time to time, SF guys forget to trap their exceptions and 
they 
bubble up in APEX!).

Well, SFDC guys should have known this before they came up with this GAE 
library.

One solution is to retry your query by wrapping it in try ... catch.

Venkat Polisetti

Original comment by venkat.p...@gmail.com on 11 Dec 2009 at 6:04

GoogleCodeExporter commented 8 years ago 
I thought it might be related to querying for many many records.  However, I 
thought 
that's what queryMore() was for:
http://www.salesforce.com/us/developer/docs/api/index_Left.htm#StartTopic=Conten
t%2Fs
force_api_calls_soql.htm|SkinName=webhelp

Even if I set:
connection.setQueryOptions(some low number);
I still get the ConnectionException.

David, did you have any luck with SFDC Support?

Original comment by tynia.y...@gmail.com on 11 Dec 2009 at 7:57

GoogleCodeExporter commented 8 years ago 
Hi Manoj,

I was looking to test out the behavior using API version 17.0.  This is based 
on a
suggestion from sfdc support. 

However, looking at the source code, I see that you created a non-GAE version 
for
17.0 in September, but the GAE branch does not appear to have been updated since
June.  Can you provide some information on the GAE branch supporting 17.0?
I did a quick test setting the API to 17.0 using the existing 16.0 library and 
got
the following exception:

Exception in thread "main" java.lang.RuntimeException: Unable to obtain partner
connection:Unexpected element. Parser was expecting element
'urn:partner.soap.sforce.com:orgHasPersonAccounts' but found
'urn:partner.soap.sforce.com:orgDisallowHtmlAttachments'

David

Original comment by turntwo...@gmail.com on 16 Dec 2009 at 3:43

GoogleCodeExporter commented 8 years ago 
Few things:

1. You dont have to do make a login call for every query. You can save the 
sessionId
somewhere and set it on the conectorConfig.

2. Version 17 will not solve the connection timeout issue.

3. The only difference between the GAE branch and the main wsc is the special
Transport class. I will try to add the version 17 of GAE code soon.

Original comment by manoj.ch...@gmail.com on 16 Dec 2009 at 4:32

GoogleCodeExporter commented 8 years ago 
Yes, for 1), my typical work flow is to obtain a Partner connection using the
username, password, and authentication endpoint.  From there I obtain a metadata
connection by assigning the session id to the metadata's connector config.

I've only exchanged e-mails with sfdc support, but I believe their thinking is 
that
talking to the version 17.0 endpoints may be more efficient than talking to the 
older
version endpoints. (Maybe some translation is involved if you come in on an 
older
endpoint?)

I'll look forward to the v 17.0 for GAE, thank you.

Original comment by turntwo...@gmail.com on 16 Dec 2009 at 4:41

GoogleCodeExporter commented 8 years ago 
I just uploaded WSC version 18 with support for GAE. Please try it out.

Original comment by manoj.ch...@gmail.com on 6 Apr 2010 at 11:08

GoogleCodeExporter commented 8 years ago

Original comment by manoj.ch...@gmail.com on 6 Apr 2010 at 11:09

GoogleCodeExporter commented 8 years ago 
Manoj have you amended the new fetch timeout to 10seconds with the new .jar?

Original comment by velteono...@gmail.com on 21 Jun 2010 at 2:27

GoogleCodeExporter commented 8 years ago 
I'd like to re-ask the question in Comment #39.  I've seen this bubbling up in 
my app recently and would like to ensure that the JARs I've downloaded are 
using the longer timeout.

Original comment by jamesk...@gmail.com on 20 Oct 2010 at 7:16

GoogleCodeExporter commented 8 years ago 
To answer my own question, I just noted that the error logs show this occurring 
almost exactly 5s into the request when using the latest wsc-gae.jar available 
in the downloads section.  So I dropped the jar and included the source file w/ 
the fix described above.

Original comment by jamesk...@gmail.com on 20 Oct 2010 at 7:48