Description
I have a n XMLEventReader that I use to parse a few elements from the beginning of big files. Then I call stop() to terminate it's background thread (because it is causing a lot of resources to be used if I leave it running).
The problem seems to be that there is an internal LinkedBlockingQueue with 1000 elements capacity. This queue must be full by the time I call stop(). Since I don't consume any more elements from the thread that calls stop() and the blocking list is already full, my code deadlocks:
Stack Trace
main 1
sun.misc.Unsafe.park line: not available [native method]
java.util.concurrent.locks.LockSupport.park line: 175
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await line: 2039
java.util.concurrent.LinkedBlockingQueue.put line: 350
scala.xml.pull.ProducerConsumerIterator$$anonfun$produce$1.apply$mcV$sp line: 144
scala.xml.pull.ProducerConsumerIterator$$anonfun$produce$1.apply line: 144
scala.xml.pull.ProducerConsumerIterator$$anonfun$produce$1.apply line: 144
scala.xml.pull.ProducerConsumerIterator$class.interruptibly line: 125
scala.xml.pull.XMLEventReader.interruptibly line: 27
scala.xml.pull.ProducerConsumerIterator$class.produce line: 144
scala.xml.pull.XMLEventReader.produce line: 27
scala.xml.pull.XMLEventReader.stop line: 56
pmc.IdFromNXml.apply line: 67
It looks like a bug to me. Also I don't understand the need for a separate thread. Since we're required to call stop() to stop processing, why the background thread? The class is instantiated via
new XMLEventReader(source)
and we need to close the source anyway, so it could all be done within the same thread.