[
https://issues.apache.org/jira/browse/CMIS-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191593#comment-14191593
]
Karam edited comment on CMIS-863 at 10/31/14 8:38 AM:
------------------------------------------------------
Hi Florian,
We've dug deeper into that issue
Seems that the problem does not come from the file itself but is related to
network issues.
I see that the DotCMIS DLL is doing "Chunked Transfer Encoding" of Base64
encoded values which is logical for and upload operation.
I guess that when there are network issues, the server may receive incomplete
chunck and tries to Base64 decode them. This leads to a corrupted Base64 decode
and generate an exception.
We've been able to successfully transfer the failing files by decreasing the
BufferSize in the AtomEntryWrite method of the AtomWriter class from 64 * 1024
to 32 * 1024
and by modifing the WebRequest in the Invoke method of the HttpUtils class by
adding :
ServicePointManager.DefaultConnectionLimit = 1000;
conn.ServicePoint.Expect100Continue = false;
conn.KeepAlive = true;
conn.Timeout = System.Threading.Timeout.Infinite;
conn.ProtocolVersion = HttpVersion.Version10;
conn.AllowWriteStreamBuffering = false;
Maybe all of this is not usefull. I'll have to make more testing.
Does it seems logical to you ?
was (Author: fka):
Hi Florian,
We've dug deeper into that issue
Seems that the problem does not come from the file itself but is related to
network issues.
I see that the DotCMIS DLL is doing "Chunked Transfer Encoding" of Base64
encoded values which is logical for and upload operation.
I guess that when there are network issues, the server may receive incomplete
chunck and tries to Base64 decode them. This leads to a corrupted Base64 decode
and generate an exception.
We've been able to successfully transfer the failing files by decreasing the
BufferSize in the AtomEntryWrite from 64 * 1024 to 32 * 1024
and modifing the WebRequest in the Invoke method of the HttpUtils class by
adding :
ServicePointManager.DefaultConnectionLimit = 1000;
conn.ServicePoint.Expect100Continue = false;
conn.KeepAlive = true;
conn.Timeout = System.Threading.Timeout.Infinite;
conn.ProtocolVersion = HttpVersion.Version10;
conn.AllowWriteStreamBuffering = false;
Maybe all of this is not usefull. I'll have to make more testing.
Does it seems logical to you ?
> Error uploading some files
> --------------------------
>
> Key: CMIS-863
> URL: https://issues.apache.org/jira/browse/CMIS-863
> Project: Chemistry
> Issue Type: Bug
> Components: dotcmis
> Affects Versions: DotCMIS 0.6
> Environment: Windows 7 X64 Client against Alfresco 4.2.e
> Reporter: Karam
> Assignee: Florian Müller
> Priority: Critical
>
> Hi,
> I encounter an error uploading a file with DotCMIS 0.6 against an Alfresco
> 4.2.e server (I don't know the version of the embedded openCMIS component).
> For certain files, I get on the server :
> [impl.atompub.CmisAtomPubServlet] [ajp-apr-8009-exec-10] Base64 input not
> properly padded.
> this raise the folowing exception on the client component :
> DotCMIS.Exceptions.CmisConnectionException: Cannot access
> https://xxx/core/cmisatom/85f01a87-4402-43c5-b18f-d1b0286b81c5/children?id=workspace://SpacesStore/98e634ee-9291-4fe2-bca9-672f64ba6e61:
> La demande a été abandonnée : La demande a été annulée. --->
> System.Net.WebException: La demande a été abandonnée : La demande a été
> annulée.
> Is this a known issue ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
