[
https://issues.apache.org/jira/browse/AXIOM-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079070#comment-13079070
]
Andreas Veithen commented on AXIOM-377:
---------------------------------------
Here is the current plan:
Attachments should return DataHandler instances that expose an interface
similar to the StreamingDataHandler class used in the JAX-WS reference
implementation, in particular the following method:
InputStream readOnce();
This would allow application code to request the attachment to be streamed.
This would also be used when an MTOM message is serialized using
serializeAndConsume. In all other cases (access using the standard DataHandler
methods; multiple attachments that are not accessed sequentially), the
attachment would be buffered so that streaming unaware application code will
continue to work as usual. It also means that streaming doesn't require any
additional configuration.
In principle this is almost trivial to implement. However, there are a couple
of constraints related to existing code that need to be taken into account:
* Axiom already defines various custom DataHandler and DataSource
implementations/extensions such as CachedFileDataSource and DataHandlerExt. We
need to make sure that we continue to support them if we determine that they
are still necessary.
* All accesses to temporary files happen through LifecycleManager/FileAccessor.
FileAccessor currently also acts as a factory for DataHandler objects for
attachments buffered on disk. This is a problem because we need to create
DataHandler instances that support streaming, but streaming is not a concern of
FileAccessor.
For most of the code related to these classes, unit test coverage is
insufficient or non existing (in particular for the changes in AXIOM-269) [We
should forbid committing any code not covered by unit tests :-(]. Therefore we
first need to write a couple of unit tests that allow us to ensure non
regression for the features we want to preserve.
Note that the solution is suboptimal (but works) in the following scenarios
(where Sadeep's patch would simply fail):
* MTOM + data binding + multiple attachments: only the last attachment can be
streamed because the data binding requests all DataHandler objects before
invoking the service, which means that all attachments except the last one will
be buffered
* forwarding an MTOM message where the attachments are in a different order
than the xop:Include elements referencing them: in this case, the order in
which the serializer requests the data handlers doesn't allow streaming of all
attachments
> When a multipart message is built, there should be a way to retrieve a
> DataHandler to the MTOM part without reading the entire incoming stream
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AXIOM-377
> URL: https://issues.apache.org/jira/browse/AXIOM-377
> Project: Axiom
> Issue Type: New Feature
> Reporter: Sadeep Jayasumana
> Assignee: Andreas Veithen
> Attachments: AXIOM-377.patch
>
>
> This feature is particularly useful when large attachments are used. Building
> large attachments in memory drives the system OOM and building them on files
> dramatically reduces performance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
