Hi Uwe,
The current code base (in trunk) does not do eager parsing.
- Florian
Hi Florian,
I investigated the streaming issue a bit and found that
"parseEagerly=true" in the JAX-WS annotation
@StreamingAttachment(parseEagerly = true, memoryThreshold = 4 * 1024
* 1204)
which is applied to OpenCMIS' ObjectService and VersioningService
breaks streaming.
Setting it to false has the following effect:
- no MIME*.temp files in Tomcat's temp directory
- the content stream's read() is called only a few times before the
service is invoked (whereas with parseEagerly=true the complete
content was read before the service's invokation and before all
handler invokations)
- in a small dev environment no negative performance impact was
observed
Would you please explain what was the intention to user eager
parsing?
Would it make sense to make this a configurable parameter as the
memoryThreshold already is?
Thanks
Uwe
-----Original Message-----
From: Florian Müller [mailto:f...@apache.org]
Sent: Mittwoch, 23. Oktober 2013 19:36
To: dev@chemistry.apache.org
Cc: Uwe Geisert
Subject: Re: Streaming capability with WS binding
Hi Uwe,
The abilities to stream, buffer in memory, buffer on disk, encrypt,
and dealing with attachments in general are implementation details
of
the JAX-WS framework and not covered by the JAX-WS specification.
OpenCMIS supports streaming if the Sun JAX-WS RI is used. The
WSConverter checks for each stream if "read once" is available and
use
it, if it is available.
But it is really easy to break. For example, putting a SOAP Handler
in front of the service can force the JAX-WS implementation to read
the whole content into memory.
OpenCMIS does not use mimepull directly. It's a dependency of the
Sun JAX-WS RI. We can't influence how the Sun JAX-WS RI uses it and
when it uses the feature you have mentioned.
The only way to get full control is to develop our own Web Services
stack and I doubt that we will do that.
- Florian
Hi,
With Webservice-binding uploaded content gets loaded completely on
the server (either in memory or on disk, depending on the size, as
specified in the StreamingAttachment's memoryThreshold).
This issue has been discussed before in regards to encryption and
configurability of the threshold.
But I wonder why content must be buffered at all.
According to https://mimepull.java.net, streaming should be possible
if
- "The parts are accessed in the same order as they appear in the
stream"
- "The parts are accessed only once."
I believe the read-once condition is complied with by OpenCMIS
(org.apache.chemistry.opencmis.commons.impl.WSConverter).
So why is streaming not possible with OpenCMIS?
Thanks for a short explanation (or even a solution ;-)
Uwe
