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/14 09:21:32 UTC

[jira] Closed: (WSCOMMONS-247) choosing attachment file caching strategy is broken

     [ https://issues.apache.org/jira/browse/WSCOMMONS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Stochmialek closed WSCOMMONS-247.
----------------------------------------

    Resolution: Invalid


I'll close the issue for now, since the "condition gap" was just misunderstanding
of current implementation. Although I like your suggestion, Scheu. And in my spare time
I'll try to implement it (unless Thilina was right). 

> 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org