Hi AJ,
Thanks for your investigations!
I will look into it and have created a JIRA issue [1] to track it.
- Florian
[1] https://issues.apache.org/jira/browse/CMIS-955
OK, also editing atompub-writer.cs, AtomEntryWriter.Write() method to
use a 64k buffered output stream helps that scenario
OK, also editing atompub-writer.cs, AtomEntryWriter.Write() method to
use a 64k buffered output stream helps that scenario (the normal,
CreateDocument scenario).
using (BufferedStream bs = new BufferedStream(outStream, 64
* 1024))
{
using (XmlWriter wri
So that edit works well with the empty-document-then-set-content
method. It does not change the behavior of trying to send the
ContentStream as part of the CreateDocument method. :(
Wireshark consistently shows the chunk size when using the "one step
create document" as 6143 bytes. I'm tryin
Thank you for the quick reply! :)
We monitored the client-memory and found the same thing as your first
comment. It's not scalable.
We tried wrapping the ContentStream's Stream (which was a FileStream) in
a BufferedStream and set the buffer to the same size as the AtomPub
Writer's (64k). T
Hi AJ,
The whole content is buffered on the client in memory before sending if
you disable chunking. That works well for small documents but may fail
for large ones. You can run out of memory.
Chunking adds some overhead but not that much.
Have you tried wrapping the content stream that you p
We have noticed some significant performance problems storing large
content to our repository.
After wading through some of the dotCMIS code we tested setting the
HttpWebRequest's sendChunked = false (as counter intuitive as it may seem).
Setting this to false increased content transfer uploa
