[
https://issues.apache.org/jira/browse/WSCOMMONS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527089
]
Rich Scheuerle commented on WSCOMMONS-247:
------------------------------------------
Michel,
A couple key points.
1) The contentLength in this part of the code is the contentLength of the
entire message.
2) We are using the contentLength of the entire message as a heuristic to
avoid unnecessary buffering.
So the idea is, if the contentLength of the whole message is much greater than
the fileStorageThreshold (for an attachment)
then just assume that the attachment should be put in a file.
For the case that you question, the contentLength of the message >
fileStorageThreshold but < fileStorageThreshold*2.
This might be the case where we have a large soap part and several medium sized
attachments.
Under these conditions we correctly fall into category (3) and determine
whether to create a PartOnMemory or PartOnFile.
-----------------
We do need changes to the heuristic and or loading code. More work is needed.
Here are is an alternative suggestion:
Right now the code makes a decision to make a PartOnFile or PartOnMemory. It
would be nice if we had
a DynamicPart. The implementation of DynamicPart could keep the bytes in
memory until the fileStorageThreshold was hit and then
silently convert to putting the bytes on file. This kind of mechanism would
allow us to avoid heuristics and buffering.
It would also work better in conditions where the incoming message is not
chunked (i.e. there is no contentLength).
I suggest that you close this issue, or help provide a more longterm solution.
Thanks,
Scheu
> choosing attachment file caching strategy is broken
> ---------------------------------------------------
>
> Key: WSCOMMONS-247
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-247
> Project: WS-Commons
> Issue Type: Bug
> Components: AXIOM
> Reporter: Michal Stochmialek
>
> The bug is a gap in conditions while choosing file caching strategy:
> if (contentLength != 0 &&
> contentLength <= fileStorageThreshold) {
> // Since the content-length is less than the threshold, we can safely
> // store it in memory.
> // [... creating a Part in memory ...]
> } else if (contentLength != 0 &&
> contentLength > fileStorageThreshold * 2) {
> // The content-length is much bigger than the threshold, then always
> // store the attachments in a file. This prevents unnecessary
> buffering.
> // [... creating a port in file ...]
>
> } else {
> // Read chunks of data to determine the size
> // of the attachment. This can wasteful because we need to gc the
> buffers.
> // [... determining the size by reading the beginning of stream
> }
> Those conditions works fine for:
> - contentLength != 0 and contentLenght <= threshold
> - contentLength != 0 and contentLenght > threshold * 2
> - contentLength == 0
> but not for:
> - contentLength != 0 and threshold < contentLenght > threshold * 2
> In this case, the flow should go to the first condition, not the third one.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
