From: Christiaan F. <chr...@ad...> - 2009-09-21 09:02:24
|
Antoni Mylka wrote: > I actually had exactly the same idea. The XmpExtractor would read and > pump data to the JpgExtractor. There would be no problems with > multi-threading because the 'main' thread would fire up a 'side' thread > for the XmpExtractor. The JpgExtractor would work on the 'main' thread > (just as now). > > I'd say we add a method to the extractor util. Either > > extractWithExtractorSet(Set set, InputStream st, ...); > // ... is whatever else is needed > > or: > > extractWithExtractors(Extractor [] exs, InputStream st, ...); > // ... is whatever else is needed > > The first could directly be used with the set obtained from the registry > (drawback: no influence on the order), the second would require the > user to set up the order by him/herself. > > The order is important because if an extractor at the beginning of the > pipeline fails - it will block (I mean deadlock) everything else > upstream. That's why it would be best to place the most stable and > simplest extractor (like Xmp) at the beginning. > > In general we will have to implement this pipeline so that it is as > robust as possible meaning: if an extractor throws an exception, we > still need to read the stream to the very end so that upstream > extractors don't block. I think any problems here can be prevented by letting a loop in the main thread read all bytes from the InputStream and pushing them to a set of PipedOutputStreams, one for each Extractor. So none of the Extractors actually runs on the main thread. Would that work? Regards, Chris -- |