Thanks for the update. Which Android version are you using? If that solves the problem, we might also be defensive in OpenCMIS and enable the stale connection check by default.
- Florian > Hi Florian, > > Just for the record, I wanted to let you know how we resolved the problem > with the Android OpenCMIS Client reusing a stale connection. We created a > custom HttpInvoker that uses android.net.http.AndroidHttpClient under the > hood. We enabled the "stale checking" connection setting via: > > HttpConnectionParams.setStaleCheckingEnabled(params, true); > > This resolved the problem. The API for this setting says: > > This setting defines whether stale connection check is to be used. > Disabling stale connection check may result in slight performance improvement > at the risk of getting an I/O error when executing a request over a > connection that has been closed at the server side. > > ... Brian ... > Xerox Corporation > Palo Alto, California > > -----Original Message----- > From: Inouye, Brian > Sent: Thursday, June 12, 2014 9:52 AM > To: 'Florian Müller'; [email protected] > Cc: Vitaliy Khudenko > Subject: RE: Odd behavior when Android OpenCMIS Client reuses a connection > that server tried to close > > Hi Florian, > > Thank you very much for the advice! We will consult with Android developer > support on how we can resolve this issue. > > I know in one case we are definitely using a proxy server. I'll see if we > can try without a proxy server. > > ... Brian ... > > -----Original Message----- > From: Florian Müller [mailto:[email protected]] > Sent: Thursday, June 12, 2014 1:35 AM > To: [email protected] > Cc: Inouye, Brian; Vitaliy Khudenko > Subject: Re: Odd behavior when Android OpenCMIS Client reuses a connection > that server tried to close > > Hi Brian, > > OpenCMIS uses the Android HTTP client library and doesn't control the TCP > connections directly. What you described happens a level below OpenCMIS. > The Android HTTP client has known issues and those issues vary with the > Android version. To find a solution to this specific problem, please refer > to the Android documentation. > There seems to be an issue with HTTP POST (-> createDocument) somewhere. > Are you using a proxy server? If so, can you retry without it? > > There are actually two HTTP client libraries in Android. OpenCMIS uses by > default the library recommended for Gingerbread and better. > You can switch to the older library by setting the session parameter > HTTP_INVOKER_CLASS to > "org.apache.chemistry.opencmis.client.bindings.spi.http.ApacheClientHttpInvoker". > That may solve this issue ... and create others. > > > - Florian > > >> In our Android Client, using OpenCMIS 0.10.0 and AtomPub binding, we >> see OpenCMIS attempt to reuse a TCP connection that the server has >> tried to close. In response to the Client trying to reuse a >> connection that it tried to close, the server correctly replies with a >> TCP RST. We then see the Android Client respond in different ways >> depending on what type of request it was attempting to send on the TCP >> connection. >> >> Case 1: If the Client was trying to do a getChildren, OpenCMIS closes >> the connection that the server was trying to close, opens a new >> connection and uses that connection for the GetChildren request. The >> request succeeds and everyone is happy. >> >> Case 2: If the Client was trying to do a createDocument, OpenCMIS does >> NOT close the connection that the server was trying to close. >> It >> opens a new connection, but then unexpectedly closes it immediately >> after opening it. Is it confused and closing the wrong connection? >> At this point, there's no connection available for it to use. >> Eventually, OpenCMIS throws a "CmisConstraintException: Conflict". >> The request fails and nobody is happy. >> >> I have Wireshark captures that clearly show the above behaviors which >> I can make available. >> >> Is this a known issue? I didn't see anything in Jira that resembles >> it. Please let me know how I should proceed in getting this resolved. >> Thanks! >> >> ... Brian ... >> Xerox Corporation >> Palo Alto, California >
