[
https://issues.apache.org/jira/browse/AXIS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636373#action_12636373
]
Ajay Shenoy commented on AXIS-2574:
-----------------------------------
I used the GNUWin32 patch tool to do this and got the following error
C:\Documents and Settings\shenoa\Desktop\patch>patch -u -N --verbose <Call.diff
Hmm... Looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|Index: Call.java
|===================================================================
|--- Call.java (revision 530044)
|+++ Call.java (working copy)
--------------------------
Patching file Call.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 63.
Hunk #4 succeeded at 86 (offset -1 lines).
Hunk #5 succeeded at 94 with fuzz 1 (offset -1 lines).
Hunk #6 succeeded at 232 (offset -3 lines).
Hunk #7 FAILED at 282.
Hunk #8 succeeded at 309 (offset -3 lines).
Hunk #9 succeeded at 339 (offset -3 lines).
Hunk #10 succeeded at 1055 (offset -17 lines).
Hunk #11 succeeded at 1351 (offset -17 lines).
Hunk #12 succeeded at 1452 (offset -17 lines).
Hunk #13 succeeded at 1461 (offset -17 lines).
Hunk #14 succeeded at 1596 (offset -17 lines).
Hunk #15 FAILED at 1825.
Hunk #16 FAILED at 1835.
Hunk #17 FAILED at 1870.
Hunk #18 FAILED at 1912.
Hunk #19 succeeded at 1872 (offset -107 lines).
Hunk #20 succeeded at 1907 (offset -107 lines).
Hunk #21 succeeded at 2071 (offset -107 lines).
Hunk #22 FAILED at 2205.
Hunk #23 succeeded at 2559 (offset -116 lines).
Hunk #24 succeeded at 2612 (offset -116 lines).
Hunk #25 succeeded at 2734 (offset -116 lines).
Hunk #26 succeeded at 2765 (offset -116 lines).
Hunk #27 succeeded at 2888 (offset -88 lines).
Hunk #28 succeeded at 2947 (offset -88 lines).
Hunk #29 FAILED at 3100.
Hunk #30 FAILED at 3133.
Hunk #31 FAILED at 3176.
9 out of 31 hunks FAILED -- saving rejects to file Call.java.rej
done
Any thoughts?
Your help will be really appreciated.
Thanks in advance
-Ajay
> 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]
