Collector with Attachments will not synch

9391
22
12-31-2014 09:55 AM
ThomasColson
MVP Frequent Contributor

Collector with Attachments will not synch: I finally got a collector app working in the following configuration:

Point Feature Class with attachments enabled published on ArcGIS Server 10.2.2 with sync enabled;

Webmap in Portal for ArcGIS (also 10.2.2);

I can access the map and create an offline copy on a variety of Android and IoS devices.

I can create new, and update point features and sync them (most of the time).

When I create or update a point feature AND attach a photograph to it, sync fails every time with "Illegal start of token [<]".

Since this works when I'm adding or updating features with no attachments, I'm pretty sure that the service and Portal is configured correctly. Why would collector stop working when attachments are added to the mix? Unfortunately, due to IT policy, we won't be able to "upgrade" to 10.3 which, at great cost, involves dozens of servers and thousands of desktop clients.

Is there a fix for this in the 10.x suite?

0 Kudos
22 Replies
AdrianMarsden
Occasional Contributor III

Same here - I have an open call with Esri(UK) regarding this.

0 Kudos
MartinKoli2
New Contributor

I had similar problem, but with AGOL only. Do you have activated GDB versioning or editors changes tracking? Try make GDB without these services.

0 Kudos
ThomasColson
MVP Frequent Contributor

GDB Versioning is enabled, as per the ESRI documentation, which suggests that it will not work otherwise, No track editor changes. Are you saying that disabling archiving makes feature attachements work? Why would a plain old feature service work with versioning enabled (per the documentation), but adding attachements (also with versioning) fail to sync in collector?

I can collect points and sync all day long in collector, even on the FS with the attachments. As soon as I add an attachment (small > 1 mb photo)....sync fails.

0 Kudos
MartinKoli2
New Contributor

I forgot a one more problem. Dont You have the problematic feature class/service in two or more various maps? First, try to use your feature class/service in just one web map. If you need it to use in more maps, you must create copies and then append it together. Sometimes helps only create new map and with new feature class/service to solve sync problem.

If it will not help, try to turn off versioning, too.

0 Kudos
AnnaHou
New Contributor II

Just to clarify, how are the attachments added? Via "Take Photo" or via "Choose From Library"? Are you able to successfully sync the edits if attachments are added via "Take Photo"?

Regards,

Anna

0 Kudos
AdrianMarsden
Occasional Contributor III

OK two points here - my reading of the set up is that versioning should be DISABLED ArcGIS Help (10.2, 10.2.1, and 10.2.2)   - earlier versions of this help page made it clearer that versioning should not be enabled.

And for me, the mere presence of the ability to add attachments is enough to break this, not the actual adding of attachments. Also, to answer the question as a bog has been raised**, when I do add an attachment it is direct from Collector.

**BUG-000084227 : Collector for ArcGIS on iOS fails to sync edits to a feature service added as an item with stored credentials in ArcGIS.com if at least one of the features has a picture attachment made from photo library.

0 Kudos
ThomasColson
MVP Frequent Contributor

We don't have this service tied to credentials, so that is not the issue. Have also tried with photo from library, photo from camera, and just adding a text file. All the same error.

0 Kudos
AdrianMarsden
Occasional Contributor III

My investigation with Esri(UK) has revealed a mixed result - sometimes it works, sometimes not.  When it fails I get this in the server logs.

  1. com.esri.rf.RException: Error parsing multi-part request at com.esri.rf.multipart.DefaultMultipartRequestHandler.parseRequest(DefaultMultipartRequestHandler.java:72) at com.esri.rf.RFactory.newMultipartRequestHandler(RFactory.java:203) at com.esri.rf.RRequest.newInstance(RRequest.java:976) at com.esri.rf.RServlet.service(RServlet.java:86) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: org.apache.commons.fileupload.FileUploadException: Read timed out at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:381) at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126) at com.esri.rf.multipart.DefaultMultipartRequestHandler.parseRequest(DefaultMultipartRequestHandler.java:65) ... 19 more Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:532) at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:501) at org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:563) at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:124) at org.apache.coyote.http11.AbstractInputBuffer.doRead(AbstractInputBuffer.java:346) at org.apache.coyote.Request.doRead(Request.java:422) at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:290) at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:449) at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:315) at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:200) at org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:977) at org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887) at java.io.InputStream.read(InputStream.java:101) at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94) at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64) at org.apache.commons.fileupload.MultipartStream.readBodyData(MultipartStream.java:593) at org.apache.commons.fileupload.MultipartStream.discardBodyData(MultipartStream.java:619) at org.apache.commons.fileupload.MultipartStream.skipPreamble(MultipartStream.java:638) at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:961) at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:942) at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331) at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:349) ... 21 more
0 Kudos
BledarBirbo1
Occasional Contributor

Hi Adrian.

Did you figure out how to fix this issue ?

We are getting the same error.

Thanks.

0 Kudos