You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Michal Stochmialek (JIRA)" <ji...@apache.org> on 2007/09/13 12:01:40 UTC
[jira] Issue Comment Edited: (WSCOMMONS-247) choosing attachment
file caching strategy is broken
[ https://issues.apache.org/jira/browse/WSCOMMONS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527050 ]
michal.stochmialek edited comment on WSCOMMONS-247 at 9/13/07 3:00 AM:
-----------------------------------------------------------------------
Of course the patch should look something like this:
if (contentLength != 0 &&
- contentLength <= fileStorageThreshold) {
+ contentLength <= fileStorageThreshold * 2) {
// Since the content-length is less than the threshold, we can safely
was (Author: michal.stochmialek):
Of course that patch should look something like this:
if (contentLength != 0 &&
- contentLength <= fileStorageThreshold) {
+ contentLength <= fileStorageThreshold * 2) {
// Since the content-length is less than the threshold, we can safely
> 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org