[ 
https://issues.apache.org/jira/browse/PDFBOX-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14632460#comment-14632460
 ] 

Timo Boehme commented on PDFBOX-2882:
-------------------------------------

Ok, I did some further changes (rev. 1691731) but only partly what you 
suggested:
* freePages.cardinality: looking at the implementation of BitSet.cardinality 
you will see that it is calculated thus I will keep freePageCount for fast 
access
* close logic: since we have not only pages stored in RandomAccessFile but also 
in-memory pages we need to track isClosed by ourself
** I've removed setting {{raf}} to {{null}} however the synchronization is 
needed nevertheless to prevent race conditions (e.g. get a new page while we 
are closing)
** I've removed in-memory page removal
** if an IOException occurs it won't be thrown immediately now but the close 
will be completed first to ensure buffer instances trying to access ScratchFile 
will receive the 'isClosed' IOException
* {{readPage/writePage}}: check if 'wrong index' exception is because of 
'isClosed' to not get a misleading exception

So the changes will ensure a more robust behaviour even in special corner cases.

I'm open for suggestions to remove a specific synchronization or check in the 
code but I'm quite confident that I can come up with a condition which needs 
this check for robustness. In general I try to prevent all situations leading 
to NPE or other RuntimeExceptions and to ensure reliable and meaningful error 
messages.

> Improve performance when using scratch file
> -------------------------------------------
>
>                 Key: PDFBOX-2882
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-2882
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: Parsing
>    Affects Versions: 2.0.0
>            Reporter: Timo Boehme
>            Assignee: Timo Boehme
>            Priority: Minor
>         Attachments: ScratchFile.java, ScratchFileBuffer.java
>
>
> The current scratch file implementation uses many direct I/O calls which 
> slows down parsing compared with in-memory scratch buffer considerably.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to