axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karshakevich (JIRA)" <>
Subject [jira] Commented: (AXIS-1573) No error message when attachment temporary file cannot be created
Date Thu, 28 Oct 2004 15:22:33 GMT
     [ ]
Alex Karshakevich commented on AXIS-1573:

I think the problem is that org.apache.axis.attachments.ManagedMemoryDataSource.flushToDisk()
clears the memory buffer before it even starts to open the disk file. 
Just check:

    protected void flushToDisk()
            throws, {

        java.util.LinkedList ml = memorybuflist;

---->   memorybuflist = null;

        log.debug(Messages.getMessage("maxCached", "" + maxCached,
                "" + totalsz));

        if (ml != null) {
....go on to attempt to write to file

Thus memorybuflist is gone whether or not writing was successful. 
I think the intent of the catch block for SecurityException was to keep the atachment in memory,
but it will be gone. I would remove that line s.t. memory is cleared only after a successful

It's probably a good idea to put a log in org.apache.axis.attachments.ManagedMemoryDataSource.getName()
when flushToDisk() throws the IOException. This will at least alert that the file got lost.

> No error message when attachment temporary file cannot be created
> -----------------------------------------------------------------
>          Key: AXIS-1573
>          URL:
>      Project: Axis
>         Type: Bug
>     Versions: current (nightly)
>  Environment: Current CVS Axis-j, Tomcat 5.0.27, Win2K, SOAP client is Axis 1.1
>     Reporter: Alex Karshakevich

> By default Axis saves attachments in temporary files in the default temp directory. If
I forget to create this directory there will be no temp file created, and Axis will quietly
lose the contents of the attachment.
> If I create the temp directory everything works well.
> The problematic method appears to be org.apache.axis.attachments.ManagedMemoryDataSource.flushToDisk()
which only catches SecurityException.
> After failing to create the temp file the attachment behaves incorrectly when I try to
read from the DataHandler's input stream. In the call to,
memorybuflist is null (since content should be on disk), and diskCacheFile is null (since
the file has not been created), it returns 0 as the number of bytes read instead of -1 or
some exception.
> In my particular case the attachment is a zipped file, and trying to call getNextEntry()
causes an infinite loop as it tries to read the stream.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message