[jira] Updated: (AXIS-2574) Reading an attachment (slowly) can cause resource deleted error
[ https://issues.apache.org/jira/browse/AXIS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated AXIS-2574: -- Attachment: axis-2574.patch Updated version of Rodrigos patch. > Reading an attachment (slowly) can cause resource deleted error > --- > > Key: AXIS-2574 > URL: https://issues.apache.org/jira/browse/AXIS-2574 > Project: Axis > Issue Type: Bug > Components: Basic Architecture >Affects Versions: 1.2.1 >Reporter: Steve Sowerby > Attachments: axis-2574.patch, Call.diff, Call.diff, Call.java > > > 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. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS-2574) Reading an attachment (slowly) can cause resource deleted error
[ https://issues.apache.org/jira/browse/AXIS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rodrigo Ruiz updated AXIS-2574: --- Attachment: Call.java I add the patched class, just in case. > Reading an attachment (slowly) can cause resource deleted error > --- > > Key: AXIS-2574 > URL: https://issues.apache.org/jira/browse/AXIS-2574 > Project: Axis > Issue Type: Bug > Components: Basic Architecture >Affects Versions: 1.2.1 >Reporter: Steve Sowerby > Attachments: Call.diff, Call.diff, Call.java > > > 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. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS-2574) Reading an attachment (slowly) can cause resource deleted error
[ https://issues.apache.org/jira/browse/AXIS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rodrigo Ruiz updated AXIS-2574: --- Attachment: Call.diff Sorry, the previous patch was broken and led to compile errors. This is the correct one. > Reading an attachment (slowly) can cause resource deleted error > --- > > Key: AXIS-2574 > URL: https://issues.apache.org/jira/browse/AXIS-2574 > Project: Axis > Issue Type: Bug > Components: Basic Architecture >Affects Versions: 1.2.1 >Reporter: Steve Sowerby > Attachments: Call.diff, Call.diff > > > 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. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS-2574) Reading an attachment (slowly) can cause resource deleted error
[ https://issues.apache.org/jira/browse/AXIS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rodrigo Ruiz updated AXIS-2574: --- Attachment: Call.diff The problem is that the Call object finalization triggers a chain of finalisations that ends in the disposal of all the AttachmentPart instances in the response message (among other things). When finalised, AttachmentPart closes the internal datahandler, and deletes the file associated. This last step is the source for the error. The file is deleted from the filesystem while it is being read. This patch uses a WeakHashMap to keep a hard reference to the Call instance from where the attachments were obtained. This way, the Call instance will not be garbage collected while the attachments are being processed. I am not sure this is an all-cases solution, but it does work for me. > Reading an attachment (slowly) can cause resource deleted error > --- > > Key: AXIS-2574 > URL: https://issues.apache.org/jira/browse/AXIS-2574 > Project: Axis > Issue Type: Bug > Components: Basic Architecture >Affects Versions: 1.2.1 >Reporter: Steve Sowerby > Attachments: Call.diff > > > 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. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
