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:29:32 UTC
[jira] Created: (WSCOMMONS-248) Attachment class shouldn't cache
soap part in file
Attachment class shouldn't cache soap part in file
--------------------------------------------------
Key: WSCOMMONS-248
URL: https://issues.apache.org/jira/browse/WSCOMMONS-248
Project: WS-Commons
Issue Type: Improvement
Components: AXIOM
Reporter: Michal Stochmialek
Since the caching strategy (to cache in file or not) is based on content-length of whole mime message,
all attachments are stored in files no matter if they're small or big. This also includes soap part, which
is usually small comparing to other attachments.
I believe that it would be difficult to get content length from every mime part, since the Content-Length
is rarely provided. Although IMHO it would be wise to not cache soap part by default.
The patch for Attachments.getPart method could look like this:
if (fileCacheEnable) {
try {
if (contentLength != 0 &&
- contentLength <= fileStorageThreshold) {
+ contentLength <= fileStorageThreshold
+ || partIndex == 0) {
// Since the content-length is less than the threshold, we can safely
- // store it in memory.
+ // store it in memory. Other option: part is a soap part.
if (log.isDebugEnabled()) {
log.debug("Creating an Attachment Part (in memory)");
}
--
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
[jira] Resolved: (WSCOMMONS-248) Attachment class shouldn't cache
soap part in file
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rich Scheuerle resolved WSCOMMONS-248.
--------------------------------------
Resolution: Fixed
Committed 575430
> Attachment class shouldn't cache soap part in file
> --------------------------------------------------
>
> Key: WSCOMMONS-248
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-248
> Project: WS-Commons
> Issue Type: Improvement
> Components: AXIOM
> Reporter: Michal Stochmialek
> Assignee: Rich Scheuerle
>
> Since the caching strategy (to cache in file or not) is based on content-length of whole mime message,
> all attachments are stored in files no matter if they're small or big. This also includes soap part, which
> is usually small comparing to other attachments.
> I believe that it would be difficult to get content length from every mime part, since the Content-Length
> is rarely provided. Although IMHO it would be wise to not cache soap part by default.
> The patch for Attachments.getPart method could look like this:
> if (fileCacheEnable) {
> try {
> if (contentLength != 0 &&
> - contentLength <= fileStorageThreshold) {
> + contentLength <= fileStorageThreshold
> + || partIndex == 0) {
> // Since the content-length is less than the threshold, we can safely
> - // store it in memory.
> + // store it in memory. Other option: part is a soap part.
> if (log.isDebugEnabled()) {
> log.debug("Creating an Attachment Part (in memory)");
> }
--
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
[jira] Assigned: (WSCOMMONS-248) Attachment class shouldn't cache
soap part in file
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rich Scheuerle reassigned WSCOMMONS-248:
----------------------------------------
Assignee: Rich Scheuerle
Yes I agree that we should not cache the soap part. I can fix this.
See my comments in WSCOMMONS-247 for other remarks/ideas about caching attachments.
> Attachment class shouldn't cache soap part in file
> --------------------------------------------------
>
> Key: WSCOMMONS-248
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-248
> Project: WS-Commons
> Issue Type: Improvement
> Components: AXIOM
> Reporter: Michal Stochmialek
> Assignee: Rich Scheuerle
>
> Since the caching strategy (to cache in file or not) is based on content-length of whole mime message,
> all attachments are stored in files no matter if they're small or big. This also includes soap part, which
> is usually small comparing to other attachments.
> I believe that it would be difficult to get content length from every mime part, since the Content-Length
> is rarely provided. Although IMHO it would be wise to not cache soap part by default.
> The patch for Attachments.getPart method could look like this:
> if (fileCacheEnable) {
> try {
> if (contentLength != 0 &&
> - contentLength <= fileStorageThreshold) {
> + contentLength <= fileStorageThreshold
> + || partIndex == 0) {
> // Since the content-length is less than the threshold, we can safely
> - // store it in memory.
> + // store it in memory. Other option: part is a soap part.
> if (log.isDebugEnabled()) {
> log.debug("Creating an Attachment Part (in memory)");
> }
--
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