[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
