[GitHub] [lucene] rmuir commented on issue #11996: Replace custom String constructor from codepoints with constructor within java.lang.String class.
rmuir commented on issue #11996: URL: https://github.com/apache/lucene/issues/11996#issuecomment-1336386270 It's obvious you are a troll and don't know what you are talking about. We add such workarounds because we have to, not for fun. If youd like to be productive on this matter go write some tests for openjdk... They clearly need them -- 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
[GitHub] [lucene] rmuir closed issue #11996: Replace custom String constructor from codepoints with constructor within java.lang.String class.
rmuir closed issue #11996: Replace custom String constructor from codepoints with constructor within java.lang.String class. URL: https://github.com/apache/lucene/issues/11996 -- 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
[GitHub] [lucene] uschindler commented on pull request #11987: Make Decompressor release memory buffer
uschindler commented on PR #11987: URL: https://github.com/apache/lucene/pull/11987#issuecomment-1336395938 Hi, another idea about the threadlocals: Why do we need thread locals "per" indexreader. A single thread local cannot be used from multiple threads, so it does not matter if multiple index readers/writers share the same thread locals. Let's do it like it is done for direct buffers inside the JDK's code, too: Let StoredFieldsReader allocate a single buffer per thread in a conventional ThreadLocal, not a closeable one (which has other problems). That is by the way how ThreadLocals are meant to be used. Of course if one has thread pools with 10.000 Threads like Solr this may still a resorce problem, but that's not Lucene's fault. So my poposal would be: Use a single ThreadLocal (non closeable) for decompression buffers in a static final field of the Decompressor class. -- 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
[GitHub] [lucene] rmuir commented on pull request #11987: Make Decompressor release memory buffer
rmuir commented on PR #11987: URL: https://github.com/apache/lucene/pull/11987#issuecomment-1336397936 The threadlocals (closeable or not, i want them out here) only exist because the api is dumb and stateless: `indexreader.document(i)`. So there's no place to store any state to reuse across multiple documents. hence threadlocal is used to workaround a problematic API. i propose we fix the api, then no threadlocal is needed anymore. -- 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
[GitHub] [lucene] rmuir commented on pull request #11987: Make Decompressor release memory buffer
rmuir commented on PR #11987: URL: https://github.com/apache/lucene/pull/11987#issuecomment-1336398355 > Hi, another idea about the threadlocals: Why do we need thread locals "per" indexreader. A single thread local cannot be used from multiple threads, so it does not matter if multiple index readers/writers share the same thread locals. Let's do it like it is done for direct buffers inside the JDK's code, too: Let StoredFieldsReader allocate a single buffer per thread in a conventional ThreadLocal, not a closeable one (which has other problems). That is by the way how ThreadLocals are meant to be used. > > Of course if one has thread pools with 10.000 Threads like Solr this may still a resorce problem, but that's not Lucene's fault. > > So my poposal would be: Use a single ThreadLocal (non closeable) for decompression buffers in a static final field of the Decompressor class. I think you are confused. There is much more than just this buffer underneath threadlocal today. -- 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
[GitHub] [lucene] xtonik commented on issue #11996: Replace custom String constructor from codepoints with constructor within java.lang.String class.
xtonik commented on issue #11996: URL: https://github.com/apache/lucene/issues/11996#issuecomment-1336413434 It's obvious you are completely out of reality. Do you think I spend my free time to do such things? If you are so clever, explain what is wrong with original implementation, I have not found any details about mentioned bugs - this should be clearly described in commit message or elsewhere - based on this information it is possible to write test, not so without. And last but not least there is written remark about necessity of verification of my suggestion. About my comments about incorrectness of custom implementation - it is evident, that I have right on first look to source code. I went through early whole Lucene project to find something worthy to contribute I really don't realize that I get so much disgusting response, I have prepared some other proposals, but I don't want communicate with other developers in such way so I will not continue to cooperate in this project anymore. -- 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
