Resolution: Not A Problem
Affects Version/s: tools-1.5.3, 1.6.0
Fix Version/s: None
Environment:Ubuntu 14.04.3 LTS
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
I'm actually not sure if this is really a "Major" "Bug" as I have listed it, perhaps it is by design. However even in this case this issue should possibly be listed as an "Improvement".
Steps to recreate:
1. Run 2 or more threads simultaneously which make calls to the same parser object with the same piece of text.
2. One of a couple of things happens:
(a) Either: line 281 of opennlp.tools.parser.AbstractBottomUpParser throws a java.util.ConcurrentModificationException from java.util.ArrayList iterator due to the `odh` field being global/shared in the object and not local to the method.
(b) Or: the opennlp.tools.postag.DefaultPOSContextGenerator.getContext method throws a NullPointerException from line 77 of the opennlp.tools.util.Cache.clear method, since the underlying opennlp.tools.util.DoubleLinkedListElement is altered out from underneath it.
Unless there are serious memory reasons for doing so, I would propose that such fields could be made local to the method since thread safety may take precedence over the memory saved in this case. As is, any code that calls the parser has to be enclosed in a giant synchronized block, and all applications using the parser have serious performance issues/cannot make use of modern hardware. I could be way of the mark here though if there is method to the madness