[
https://issues.apache.org/jira/browse/LUCENE-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466539#comment-17466539
]
ASF subversion and git services commented on LUCENE-10342:
----------------------------------------------------------
Commit df4562d14907b2876937af217d80805630e5d4ba in lucene's branch
refs/heads/branch_9x from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=df4562d ]
LUCENE-10342: Add logging to static initializers to warn users if unmapping or
object size calculation does not work (#572)
Co-authored-by: Tomoko Uchida <[email protected]>
# Conflicts:
#
lucene/facet/src/java/org/apache/lucene/facet/taxonomy/directory/DirectoryTaxonomyReader.java
> Add (very limited) java.util.logging to Lucene Core
> ---------------------------------------------------
>
> Key: LUCENE-10342
> URL: https://issues.apache.org/jira/browse/LUCENE-10342
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/other
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Priority: Critical
> Labels: flamewar, logging
> Time Spent: 11.5h
> Remaining Estimate: 0h
>
> At the moment we have some parts in Lucene where we check for features of the
> JDK and use them, only if available:
> - We only use MMapDirectory, if we can unmap, so sun.misc.Unsafe must be
> available
> - To correctly calculate heap space requirements of data structures for
> caching and other types of buffers, we try to calculate the heap size of
> objects. To do this correctly we need some information like the size of
> ordinal object pointers. If they are 32 bits on 64 bit platforms, the memory
> usage of Object[] arrays (and HashSet/HashMaps) dramatically reduce size by
> factor of 2.
> As those checks require "optional" modules in the java module system, which
> may not even be available by default as they are unsupported, we do the check
> dynamically.
> In Classpath mode, this are all nobrainers, because the modules are available
> by default. But as soon as downstream code switches to module mode, the whole
> things may suddenly stop working (because module was forgotten) for the
> application and nobody notices. A user of Lucene may then need to add those
> modules to the module descriptor of the application or pass on command line
> (to make it optional if the JVM supports it, e.g. what happens if
> "jdk.unsupported" is not available for custom JDK xy by provider Z?). If
> heshe misses to add the module or for some other reason it does not work
> (like feature is not available in J9 instead of Hotspot), we silently disable
> MMapDirectory or for memory usage we may be off by an factor of 2.
> My suggestion is now to enable java.util.logging in Lucene's core (maybe also
> in other modules, too - luke is already) and report such warnings using
> java.util.logging. Any downstream code will see the logging then depending on
> the used logging system (log4j, slf4j with correct wrapper module).
> I know this suggestion may cause a bit a flame war because of disagreement
> about pros and cons about if logging is needed, so I'd like to limit this to
> warnings+. We won't ever emit info/debug/trace. To make sure we only log
> "warn" and "error"/"severe" events, I will add a forbiddenapis rule to deny
> all other loglevels. The added logging will only appear once at application
> startup because I will add them only to static initializers.
> As a side effect I will also add an IndexWriter log stream implementation for
> java.util.logging to make it easy to log infostream events during indexing
> through a logging system.
> I will provide a PR adding 2 warnings and the InfoStream implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
