Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 1.6
-
Fix Version/s: 2.0
-
Component/s: o.c.jsword.book.sword
-
Labels:None
-
Environment:
Every OS defines the open file handle limit differently. It may differ from one installation to another. I hit it with 500+ modules on a Mac OS X 10.10.
Description
The OFSM manages pools of open file states per book/module. In a single threaded application this pool is never longer than one. If a book is not accessed a pool is not created. If multiple threads simultaneously access the same book, then open file states are created to match this number. The pool grows when open file states are returned. So far so good.
The problems:
Each pool is unbounded.
Each pool never shrinks.
The FIFO (First In/First Out) policy, which has no effect, should be LIFO (Last In/First Out).
Invalid OpenFileStates are added to the pool (I think this is the case but have to verify.)
When the number of books or the level of concurrency is high, this will result in new open files states being unable to open their files. (I encountered this when trying to read all 500+ modules one after the other).
The solution:
Pool should be bounded. That is when adding to a full pool, an object is evicted.
Pool protocol should be LIFO to support MRU (Most recently used) or MFU (Most frequently used).
There should be a LRU pool eviction policy. This should be triggered on a regular basis.