You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2012/10/24 09:30:12 UTC

[jira] [Created] (DERBY-5960) VirtualRandomAccessFile.close() is not idempotent

Knut Anders Hatlen created DERBY-5960:
-----------------------------------------

             Summary: VirtualRandomAccessFile.close() is not idempotent
                 Key: DERBY-5960
                 URL: https://issues.apache.org/jira/browse/DERBY-5960
             Project: Derby
          Issue Type: Bug
          Components: Store
    Affects Versions: 10.10.0.0
            Reporter: Knut Anders Hatlen
            Assignee: Knut Anders Hatlen
            Priority: Minor


If VirtualRandomAccessFile.close() is called more than once, which might happen in code that cleans up after errors, it will throw a NullPointerException. We should make close() idempotent so that it is more robust.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DERBY-5960) VirtualRandomAccessFile.close() is not idempotent

Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen resolved DERBY-5960.
---------------------------------------

          Resolution: Fixed
       Fix Version/s: 10.10.0.0
    Issue & fix info:   (was: Patch Available)

Committed revision 1402111.
                
> VirtualRandomAccessFile.close() is not idempotent
> -------------------------------------------------
>
>                 Key: DERBY-5960
>                 URL: https://issues.apache.org/jira/browse/DERBY-5960
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.10.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>             Fix For: 10.10.0.0
>
>         Attachments: d5960-1a.diff
>
>
> If VirtualRandomAccessFile.close() is called more than once, which might happen in code that cleans up after errors, it will throw a NullPointerException. We should make close() idempotent so that it is more robust.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5960) VirtualRandomAccessFile.close() is not idempotent

Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-5960:
--------------------------------------

    Attachment: d5960-1a.diff

Attaching a fix, including a test case in VirtualFileTest.

The patch simply makes close() stop nulling out the fields so that it won't run into a NPE on subsequent executions.

(I preferred that approach to adding extra null checks in close(), as it allows the code to be slightly shorter/simpler. The advantage of nulling the fields and adding extra checks would be that the objects references by the fields would be eligible for gc earlier if the VirtualRandomAccessFile instance itself was still referenced after close(). I believe that this is not the case in normal use of VRAF. And even if it is used that way, there's not much to gain since the big data structures (the byte arrays) in those instances are already freed. So adding extra code to optimize for that case didn't seem worthwhile.)

I also used the opportunity to fix a typo in VirtualFile and make some of the fields in VirtualRandomAccessFile final.

All the regression tests ran cleanly with the patch.
                
> VirtualRandomAccessFile.close() is not idempotent
> -------------------------------------------------
>
>                 Key: DERBY-5960
>                 URL: https://issues.apache.org/jira/browse/DERBY-5960
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.10.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d5960-1a.diff
>
>
> If VirtualRandomAccessFile.close() is called more than once, which might happen in code that cleans up after errors, it will throw a NullPointerException. We should make close() idempotent so that it is more robust.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5960) VirtualRandomAccessFile.close() is not idempotent

Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-5960:
--------------------------------------

    Issue & fix info: Patch Available
    
> VirtualRandomAccessFile.close() is not idempotent
> -------------------------------------------------
>
>                 Key: DERBY-5960
>                 URL: https://issues.apache.org/jira/browse/DERBY-5960
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.10.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d5960-1a.diff
>
>
> If VirtualRandomAccessFile.close() is called more than once, which might happen in code that cleans up after errors, it will throw a NullPointerException. We should make close() idempotent so that it is more robust.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira