axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edith Birrer (JIRA)" <axis-...@ws.apache.org>
Subject [jira] Commented: (AXIS-2574) Reading an attachment (slowly) can cause resource deleted error
Date Tue, 07 Nov 2006 15:52:51 GMT
    [ http://issues.apache.org/jira/browse/AXIS-2574?page=comments#action_12447835 ] 
            
Edith Birrer commented on AXIS-2574:
------------------------------------

Concerning the problem with the deleted resources, I found something which could give a hint
about what a solution could be.
By the way, this is now in Axis 1.4 . (I found a way around the problem mentioned in AXIS-2585
- used the missing class "stolen" from Axis 1.3).

To track the creation and deletion of the attachments, I used remote debugging from Eclipse
into Tomcat and set a breakpoint in AttachmentPart.<init>(DataHandler) and one in AttachmentPart.dispose()
[or in AttachmentImpl.dispose() ]. Additionally I watched the data flow in SOAP-Monitor.

For the findings it is important to understand the environment; here a short description.
I have server which runs two webservices: 
-- The "main" webservice receives requests which contain a data file (in a DataHandler) and
stores them in a queue. (It can also deliver the result of the request back to the caller,
but this is not important for now). 
-- The "queue" webservice is called by "workers" which use it to take requests from the queue,
work on them and give the result back to the queue.


So the the story of a request is as follows:
1. The request object (containing a DataHandler) is sent to the webservice: Axis transfers
the attachment and then may finalize (and delete) it.
2. A worker has nothing to do and requests work from the queue. In the response he receives
the request object (still containing the DataHandler), so Axis again transfers the attachment
(but this time it is a send operation and not a receive). 
3. The worker works on it, creates two result files and attaches them to the request object.
Then the whole thing is transferred back to the queue: Axis again transfers all attachments
(now 3) and then may finalize them. 

AttachmentsImpl has a map of AttachmentPart. Whenever a message is disposed, all its Attachments
are disposed. The chain is:
MessageContext.dispose() -> Message.dispose() -> AttachmentsImpl.dispose() 
and the latter loops over all AttachmentPart and disposes them.

Now the interesting thing:
Step 1 of the above creates an entry with the id of the DataHandler, and after transfer, the
AttachmentPart will be deleted. The same object used in step 1 comes back in step 3. It still
contains the same DataHandler, untouched by the application. In addition it contains 2 new
attachments. Thus, step 3 has to transfer 3 attachments. However, for the first Attachment,
the corresponding AttachmentPart has been deleted in step 1! Axis somehow does not create
a new one, but just finds that the file (the file in the AxisAttachments directory) has been
deleted (which is correct). 

I tried the following: As there is no reason to give back in step 3 the original data from
step 1, I changed the worker: after storing the data file, it sets the DataHandler field in
the request object to null. So in step 3, only the two new attachments have to be transferred.
This works, I never get the "Resource has been deleted" message!!! (unless I use the debugger
to stop all calls to AttachmentPart.<init>(DataHandler) and only let through the calls
to AttachmentPart.dispose() - but in reality this should not happen...)

So to me it looks like a DataHandler can only be transferred once with Axis. If you need to
transfer the same file again, you have to create a new DataHandler.  Or better, check if you
re-transfer files which you don't really need to and eliminate that.
Peggy, maybe this is also the case in your application?

A DataHandler object can only be transferred once with Axis - I wonder if this is the intended
behaviour? If it is, shouldn't it be mentioned somewhere? Or if it isn't, why does Axis not
create again an AttachmentPart for it?


> Reading an attachment (slowly) can cause resource deleted error
> ---------------------------------------------------------------
>
>                 Key: AXIS-2574
>                 URL: http://issues.apache.org/jira/browse/AXIS-2574
>             Project: Apache Axis
>          Issue Type: Bug
>          Components: Basic Architecture
>    Affects Versions: 1.2.1
>            Reporter: Steve Sowerby
>
> When reading the data from an attachment we periodically get the following error:
> java.io.IOException: Resource has been deleted.
>  at org.apache.axis.attachments.ManagedMemoryDataSource$Instream.read(ManagedMemoryDataSource.java:688)
> Having run this throught a debugger and had a brief look at the code it seems to me there
is a race condition of sorts.
> The MemoryManagedDataSource that provides the InputStream has been marked as deleted
by the finalize method of AttachmentPart.
> So basically if the client doesn't read off the attachment fast enough then the writer
will have finished and the AttachmentPart gets finalized and blam, you've got a deleted MemoryManagedDataSource.
> I'm not sure what the best fix is.  Perhaps the deletion should actually be some reference
count rather than a simple boolean.  That way the MemoryManagedDataSource gets deleted once
all the writers and readers are done?  Although perhaps then there would be an issue if the
client was very slow to even open the attachment?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message