rmuir commented on pull request #2429: URL: https://github.com/apache/lucene-solr/pull/2429#issuecomment-785256914
> > As a result > > it is now possible to call BytesRefHash#find concurrently as long as there are > > no concurrent modifications to BytesRefHash instance and it is correctly published. > > This feels like a trap waiting for somebody to fall in. I think a better solution would be a pool of buffers and proper concurrency controls around them, but don't know what the performance would look like. > > At a minimum, we need to update the method javadoc to explain what is going on and what proper usage looks like. sorry I don't think it is a trap really. Everything else using this thing is using it in a per-thread way. A lot of lucene works this way, it keeps things fast. I don't think we should slow down all the correct users and add complex concurrency, just because we have one module abusing it. This would be equivalent to making all java code use HashTable/StringBuffer when most code only needs HashMap/StringBuilder. We could easily slow down important things such as indexing. See my comments on the issue. ---------------------------------------------------------------- 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. 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
