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:32 UTC

[jira] Commented: (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 commented on WSCOMMONS-247:
----------------------------------------------

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