[
https://issues.apache.org/jira/browse/WSCOMMONS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527102
]
Thilina Gunarathne commented on WSCOMMONS-247:
----------------------------------------------
Hi Scheu,
>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.
Though the decision happens outside of the parts, effectively the behaviour was
supposed to be what you are talking about. We buffer the bytes in memory until
some threshold occurs and then changes to putting the contents in to a
PartOnFile if it exceeds the limit. If not the buffer will be parsed to the
PartOnMemory.
I see the dynamic part you are proposing only as moving the above code bit in
to that from the current place..
Anyway not sure whether I got you correct. Correct me if I'm misunderstanding
the proposal.
> 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
> Assignee: Rich Scheuerle
>
> 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]
