kotman12 commented on PR #11955: URL: https://github.com/apache/lucene/pull/11955#issuecomment-1322109984
> > Thanks for the clarification, that does make things simpler to analyze. I still think there is a race condition between parallel calls to `FilterFactory:create` mainly because of unsynchronized, lazy initialization of singleton members within open-nlp that actually gets invoked from lucene's factory::create method (surprisingly not from the factory cctor/inform). Most of the cases I saw would probably be hard to pin down by a test but I think I'll be able to illustrate at least one of them. > > I'm not sure any tests would find such problems due to how classes get loaded. MANY libraries have races like this, the trick to working around them is to invoke `Class.forName(crappyClass)` yourself e.g. safely at program startup. > > Honestly there is nothing _another library_ like lucene can do about this. > > I plan to merge this commit in a few days. This is actually along the lines of what I currently do .. I completely bypass open-nlp factories because I don't trust them. I agree that the issue is more with open-nlp because I can't even see a good use of this lazy initialization as it doesn't really save much in terms of resource consumption or bootstrap time. Still I would think that this should be fixed _somewhere_ (assuming we agree it is an issue) and that lucene would care about it being fixed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
