[jira] [Commented] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor

[jefferyyuan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815081#comment-16815081
 ] 

jefferyyuan commented on SOLR-12833:


[~ab]Based on your suggestion, I removed versionBucketLockTimeoutMs from 
VersionBucket.

[https://github.com/apache/lucene-solr/pull/641]

Thanks.

> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 7.7, 8.0
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] jefferyyuan opened a new pull request #641: Move versionBucketLockTimeoutMs into VersionInfo

[GitBox]

jefferyyuan opened a new pull request #641: Move versionBucketLockTimeoutMs 
into VersionInfo
URL: https://github.com/apache/lucene-solr/pull/641
 
 
   


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


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Artifacts-master - Build # 3748 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Artifacts-master/3748/

No tests ran.

Build Log:
[...truncated 12086 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/build.xml:433:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/build.xml:413:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/common-build.xml:2269:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/common-build.xml:1727:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/common-build.xml:657:
 Unable to initialize POM pom.xml: Could not find the model file 
'/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/build/poms/lucene/luke/pom.xml'.
 for project unknown

Total time: 5 minutes 10 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[Fast Archiver] Compressed 271.01 MB of artifacts by 28.8% relative to #3747
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_172) - Build # 23896 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23896/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 15799 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp/junit4-J2-20190411_010544_4881067382581032370511.sysout
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: GC overhead limit exceeded
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps/java_pid17917.hprof 
...
   [junit4] Heap dump file created [487829414 bytes in 2.746 secs]
   [junit4] <<< JVM J2: EOF 

[...truncated 8965 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:633: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:585: Some of the 
tests produced a heap dump, but did not fail. Maybe a suppressed 
OutOfMemoryError? Dumps created:
* java_pid17917.hprof

Total time: 80 minutes 40 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor

[jefferyyuan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814993#comment-16814993
 ] 

jefferyyuan commented on SOLR-12833:


[~ab] I will create the pr by end of tomorrow. Thanks.

> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 7.7, 8.0
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-8.x - Build # 116 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/116/

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest

Error Message:
ObjectTracker found 5 object(s) that were not released!!! [MMapDirectory, 
InternalHttpClient, MMapDirectory, MMapDirectory, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:509)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:351) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:424) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$13(ReplicationHandler.java:1193)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.http.impl.client.InternalHttpClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:321)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330)
  at 
org.apache.solr.handler.IndexFetcher.createHttpClient(IndexFetcher.java:230)  
at org.apache.solr.handler.IndexFetcher.(IndexFetcher.java:272)  at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:420) 
 at org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:237) 
 at 
org.apache.solr.cloud.RecoveryStrategy.doReplicateOnlyRecovery(RecoveryStrategy.java:382)
  at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:328)  
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:307)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:99)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:779)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:976)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1245)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1155)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:180)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:784)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:750)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:510)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:165)
  at 

[jira] [Created] (SOLR-13393) ZkClientClusterStateProvider can leak ZkStateReader (and associated watcher threads) if background threads attempt to use it after close() .

[Hoss Man (JIRA)]

Hoss Man created SOLR-13393:
---

 Summary: ZkClientClusterStateProvider can leak ZkStateReader (and 
associated watcher threads) if background threads attempt to use it after 
close() .
 Key: SOLR-13393
 URL: https://issues.apache.org/jira/browse/SOLR-13393
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


while digging into some test failures related to leaked ZkStateReader objects, 
i noticed a pattern which i beleive can be explained by the fact that 
ZkClientClusterStateProvider does not complain/fail if some caller tries to 
connect()/use it after it's already been closed – in this situation it will 
just re-create a new ZkStateReader (which is later leaked)

So in in situations where background/timer threads use a 
SolrClientCloudManager/ZkClientClusterStateProvider, we might see...
{noformat}
T1 : start shutdown...
T1 :  ...SolrClientCloudManager.close()...
T1 :   ...ZkClientClusterStateProvider.close()...
T1 :...ZkStateReader.close()
T1 :...zkStateReader = null;
T 2: run background thread/task/trigger...
T 2:  ...get ZkClientClusterStateProvider
T 2:  ...call ZkClientClusterStateProvider.connect()
T 2:   ...zkStateReader = new ZkStateReader() /* LEAKED */
T 2:  ... do something with ZkClientClusterStateProvider
T 2:  ...finish background thread/task/trigger
T1 :  ...finish shutdown of ZkClientClusterStateProvider / 
SolrClientCloudManager
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13290) Prometheus metric exporter AsyncLogger: java.lang.NoClassDefFoundError

[Karl Stoney (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814950#comment-16814950
 ] 

Karl Stoney commented on SOLR-13290:


Possibly linked to https://issues.apache.org/jira/browse/SOLR-13392, the same 
commit seems to have broken 7x prometheus-exporter too.

> Prometheus metric exporter AsyncLogger: java.lang.NoClassDefFoundError
> --
>
> Key: SOLR-13290
> URL: https://issues.apache.org/jira/browse/SOLR-13290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 8.0, 8.1
>Reporter: Karl Stoney
>Assignee: Erick Erickson
>Priority: Major
>
> Since this 
> commit:[https://github.com/apache/lucene-solr/commit/02eb9d34404b8fc7225ee7c5c867e194afae17a0]
> The metrics exporter in branch_8x no longer starts
> {code:java}
> 2019-03-04 16:06:01,070 main ERROR Unable to invoke factory method in class 
> org.apache.logging.log4j.core.async.AsyncLoggerConfig for element 
> AsyncLogger: java.lang.NoClassDefFoundError
> : com/lmax/disruptor/EventFactory java.lang.reflect.InvocationTargetException
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:136)
>  at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:964)
>  at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:904)
>  at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:896)
>  at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:514)
>  at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:238)
>  at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:250)
>  at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:548)
>  at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:620)
>  at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:637)
>  at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
>  at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
>  at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>  at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>  at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
>  at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>  at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
>  at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>  at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>  at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>  at 
> org.apache.solr.prometheus.exporter.SolrExporter.(SolrExporter.java:48)
> Caused by: java.lang.NoClassDefFoundError: com/lmax/disruptor/EventFactory
>  at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.getAsyncLoggerConfigDelegate(AbstractConfiguration.java:203)
>  at 
> org.apache.logging.log4j.core.async.AsyncLoggerConfig.(AsyncLoggerConfig.java:91)
>  at 
> org.apache.logging.log4j.core.async.AsyncLoggerConfig.createLogger(AsyncLoggerConfig.java:273)
>  ... 25 more
> Caused by: java.lang.ClassNotFoundException: com.lmax.disruptor.EventFactory
>  at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
>  at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
>  at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>  ... 28 more{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13392) Unable to start prometheus-exporter in 7x branch

[Karl Stoney (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Stoney updated SOLR-13392:
---
Description: 
Hi, 
prometheus-exporter doesn't start in branch 7x on commit 
7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on 
26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between those 
two commits causing this.

I am presuming it is 
https://github.com/apache/lucene-solr/commit/e1eeafb5dc077976646b06f4cba4d77534963fa9#diff-3f7b27f0f087632739effa2aa508d77eR34

INFO  - 2019-04-10 23:52:30.979; org.apache.solr.core.SolrResourceLoader; solr 
home defaulted to 'solr/' (could not find system property or JNDI)
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/lucene/util/IOUtils
at 
org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881)
at 
org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221)
at 
org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205)
Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 3 more


  was:
Hi, 
prometheus-exporter doesn't start in branch 7x on commit 
7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on 
26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between those 
two commits causing this:

INFO  - 2019-04-10 23:52:30.979; org.apache.solr.core.SolrResourceLoader; solr 
home defaulted to 'solr/' (could not find system property or JNDI)
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/lucene/util/IOUtils
at 
org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881)
at 
org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221)
at 
org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205)
Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 3 more


> Unable to start prometheus-exporter in 7x branch
> 
>
> Key: SOLR-13392
> URL: https://issues.apache.org/jira/browse/SOLR-13392
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.7.2
>Reporter: Karl Stoney
>Priority: Major
>
> Hi, 
> prometheus-exporter doesn't start in branch 7x on commit 
> 7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on 
> 26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between 
> those two commits causing this.
> I am presuming it is 
> https://github.com/apache/lucene-solr/commit/e1eeafb5dc077976646b06f4cba4d77534963fa9#diff-3f7b27f0f087632739effa2aa508d77eR34
> INFO  - 2019-04-10 23:52:30.979; org.apache.solr.core.SolrResourceLoader; 
> solr home defaulted to 'solr/' (could not find system property or JNDI)
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/lucene/util/IOUtils
> at 
> org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881)
> at 
> org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221)
> at 
> org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205)
> Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 3 more



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13392) Unable to start prometheus-exporter in 7x branch

[Karl Stoney (JIRA)]

Karl Stoney created SOLR-13392:
--

 Summary: Unable to start prometheus-exporter in 7x branch
 Key: SOLR-13392
 URL: https://issues.apache.org/jira/browse/SOLR-13392
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: metrics
Affects Versions: 7.7.2
Reporter: Karl Stoney


Hi, 
prometheus-exporter doesn't start in branch 7x on commit 
7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on 
26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between those 
two commits causing this:

INFO  - 2019-04-10 23:52:30.979; org.apache.solr.core.SolrResourceLoader; solr 
home defaulted to 'solr/' (could not find system property or JNDI)
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/lucene/util/IOUtils
at 
org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881)
at 
org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221)
at 
org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205)
Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 3 more



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Issue Comment Deleted] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-8738:
--
Comment: was deleted

(was: It only looks like I can't run tests in Eclipse. It says that no test 
cases were found. I will dig into this.)

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814907#comment-16814907
 ] 

Uwe Schindler commented on LUCENE-8738:
---

It only looks like I can't run tests in Eclipse. It says that no test cases 
were found. I will dig into this.

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13391) Add variance and standard deviation stream evaluators

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814896#comment-16814896
 ] 

Joel Bernstein commented on SOLR-13391:
---

Ok, great. If you can point me to the pull request I'll take a look.

 

> Add variance and standard deviation stream evaluators
> -
>
> Key: SOLR-13391
> URL: https://issues.apache.org/jira/browse/SOLR-13391
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Nazerke Seidan
>Priority: Minor
>  Labels: pull-request-available
>
> It seems variance and standard deviation stream evaluators are not supported 
> by any of the solr version. For example, 
>               let(echo="m,v,sd", arr=array(1,3,3), m=mean(a), v=var(a), 
> sd=stddev(a))
> So far, only the mean function is implemented. I think it is useful to have 
> var and sttdev functions separately as a stream evaluator. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-8725) Make TermsQuery.SeekingTermSetTermsEnum public

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul reassigned LUCENE-8725:
--

Assignee: Noble Paul

> Make TermsQuery.SeekingTermSetTermsEnum public
> --
>
> Key: LUCENE-8725
> URL: https://issues.apache.org/jira/browse/LUCENE-8725
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Fix For: 8.1
>
>
> I have come across use-cases where directly accessing {{TermsQuery}} can 
> help. If there is no objection I would like to make it public



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814869#comment-16814869
 ] 

Uwe Schindler commented on LUCENE-8738:
---

bq. Uwe Schindler I tested Eclipse indeed. I only had issue with 
MockInitialContextFactory, Eclipse complains that it tries to access classes 
from a module it doesn't have access to.

Tested Eclipse 2019-03: Works fine. Just configure your Java 11 OpenJDK 
location and all works automatically.

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 330 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/330/

2 tests failed.
FAILED:  org.apache.solr.security.AuditLoggerIntegrationTest.testAsyncQueueDrain

Error Message:
Expecting <2 callbacks in buffer, was 2

Stack Trace:
java.lang.AssertionError: Expecting <2 callbacks in buffer, was 2
at 
__randomizedtesting.SeedInfo.seed([3E0B80CB353B5DAA:8F147FEF85F8CE75]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.security.AuditLoggerIntegrationTest.testAsyncQueueDrain(AuditLoggerIntegrationTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.client.solrj.TestLBHttp2SolrClient.testTwoServers

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:42547/solr/collection1/select?q=*%3A*=javabin=2

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while 

[JENKINS] Lucene-Solr-Tests-8.x - Build # 115 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/115/

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
Error from server at http://127.0.0.1:44593/solr/authCollection: Error from 
server at null: Expected mime type application/octet-stream but got text/html. 
   Error 401 require 
authentication  HTTP ERROR 401 Problem 
accessing /solr/authCollection_shard2_replica_n3/select. Reason: 
require authenticationhttp://eclipse.org/jetty;>Powered 
by Jetty:// 9.4.14.v20181114

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:44593/solr/authCollection: Error from server at 
null: Expected mime type application/octet-stream but got text/html. 


Error 401 require authentication

HTTP ERROR 401
Problem accessing /solr/authCollection_shard2_replica_n3/select. Reason:
require authenticationhttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.14.v20181114




at 
__randomizedtesting.SeedInfo.seed([CF37AFE811D589BC:7359D9FAB5860AC6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1055)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:830)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:763)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:290)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-11) - Build # 376 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/376/
Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test

Error Message:
Error from server at http://127.0.0.1:34459/collection1: no servers hosting 
shard: shard3

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:34459/collection1: no servers hosting shard: 
shard3
at 
__randomizedtesting.SeedInfo.seed([6452376720136887:EC0608BD8EEF057F]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.doNestedInplaceUpdateTest(NestedShardedAtomicUpdateTest.java:161)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test(NestedShardedAtomicUpdateTest.java:56)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814857#comment-16814857
 ] 

Uwe Schindler commented on LUCENE-8738:
---

Hi,
I looked a bit more on the Observer code. I think we should add type safe 
method to the abstract superclass and change the java documentation. Because 
currently without knowing what SolrCores internaly does, its impossible to do 
it right. I think I will add a method to register, deregister and to notify to 
the abstract TransientCoreCache impl. This is in line with the current 
Observerable superclass.

Alternatively we need to change the Javadocs of TransientSolrCoreCache (we need 
to adapt anyways).

I am looking for a more "type safe" way to do this.

[~erickerickson]: what do you think?

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Tomoko Uchida as Lucene/Solr committer

[Yonik Seeley]

Congrats Tomoko!
-Yonik


On Mon, Apr 8, 2019 at 11:20 AM Uwe Schindler  wrote:

> Hi all,
>
> Please join me in welcoming Tomoko Uchida as the latest Lucene/Solr
> committer!
>
> She has been working on https://issues.apache.org/jira/browse/LUCENE-2562
> for several years with awesome progress and finally we got the fantastic
> Luke as a branch on ASF JIRA:
> https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/lucene-2562-luke-swing-3
> Looking forward to the first release of Apache Lucene 8.1 with Luke
> bundled in the distribution. I will take care of merging it to master and
> 8.x branches together with her once she got the ASF account.
>
> Tomoko also helped with the Japanese and Korean Analyzers.
>
> Congratulations and Welcome, Tomoko! Tomoko, it's traditional for you to
> introduce yourself with a brief bio.
>
> Uwe & Robert (who nominated Tomoko)
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Tomoko Uchida as Lucene/Solr committer

[Alan Woodward]

Congratulations and welcome!

> On 10 Apr 2019, at 14:21, Gus Heck  > wrote:
> 
> Welcome Tomoko! :)
> 
> On Tue, Apr 9, 2019 at 1:57 PM Ahmet Arslan  > wrote:
> Congralations Tomoko!
> 
> 
> 
> 
> On Tuesday, April 9, 2019, 8:48:03 PM GMT+3, Robert Muir  > wrote: 
> 
> 
> 
> 
> 
> Welcome!
> 
> On Mon, Apr 8, 2019 at 11:21 AM Uwe Schindler  > wrote:
> >
> > Hi all,
> >
> > Please join me in welcoming Tomoko Uchida as the latest Lucene/Solr 
> > committer!
> >
> > She has been working on https://issues.apache.org/jira/browse/LUCENE-2562 
> >  for several years with 
> > awesome progress and finally we got the fantastic Luke as a branch on ASF 
> > JIRA: 
> > https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/lucene-2562-luke-swing-3
> >  
> > 
> > Looking forward to the first release of Apache Lucene 8.1 with Luke bundled 
> > in the distribution. I will take care of merging it to master and 8.x 
> > branches together with her once she got the ASF account.
> >
> > Tomoko also helped with the Japanese and Korean Analyzers.
> >
> > Congratulations and Welcome, Tomoko! Tomoko, it's traditional for you to 
> > introduce yourself with a brief bio.
> >
> > Uwe & Robert (who nominated Tomoko)
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de 
> > eMail: u...@thetaphi.de 
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > 
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > 
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> http://www.the111shift.com 

[jira] [Commented] (SOLR-13272) Interval facet support for JSON faceting

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814833#comment-16814833
 ] 

Yonik Seeley commented on SOLR-13272:
-

bq. why it's a separate type and not just optional property to type:range? 

I agree it would probably be nicer to just have it as part of a range facet... 
that way other range parameters like "other", "include", etc could be 
(eventually) supported / reused.

> Interval facet support for JSON faceting
> 
>
> Key: SOLR-13272
> URL: https://issues.apache.org/jira/browse/SOLR-13272
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Apoorv Bhawsar
>Priority: Major
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Interval facet is supported in classical facet component but has no support 
> in json facet requests.
>  In cases of block join and aggregations, this would be helpful
> Assuming request format -
> {code:java}
> json.facet={pubyear:{type : interval,field : 
> pubyear_i,intervals:[{key:"2000-2200",value:"[2000,2200]"}]}}
> {code}
>  
>  PR https://github.com/apache/lucene-solr/pull/597



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814823#comment-16814823
 ] 

Adrien Grand commented on LUCENE-8738:
--

[~thetaphi] I tested Eclipse indeed. I only had issue with 
MockInitialContextFactory, Eclipse complains that it tries to access classes 
from a module it doesn't have access to.

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-13272) Interval facet support for JSON faceting

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814370#comment-16814370
 ] 

Mikhail Khludnev edited comment on SOLR-13272 at 4/10/19 7:30 PM:
--

Also, [~ichattopadhyaya], why it's a separate type and not just optional 
property to {{type:range}}? 


was (Author: mkhludnev):
Also, [~ichattopadhyaya], why it's a separate type and not just expansion to 
\{{type:range}}?

> Interval facet support for JSON faceting
> 
>
> Key: SOLR-13272
> URL: https://issues.apache.org/jira/browse/SOLR-13272
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Apoorv Bhawsar
>Priority: Major
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Interval facet is supported in classical facet component but has no support 
> in json facet requests.
>  In cases of block join and aggregations, this would be helpful
> Assuming request format -
> {code:java}
> json.facet={pubyear:{type : interval,field : 
> pubyear_i,intervals:[{key:"2000-2200",value:"[2000,2200]"}]}}
> {code}
>  
>  PR https://github.com/apache/lucene-solr/pull/597



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 23894 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23894/
Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:-UseCompressedOops 
-XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.BasicDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=24734, 
name=testExecutor-8204-thread-2, state=RUNNABLE, 
group=TGRP-BasicDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=24734, name=testExecutor-8204-thread-2, 
state=RUNNABLE, group=TGRP-BasicDistributedZkTest]
at 
__randomizedtesting.SeedInfo.seed([496813BA41B150F6:C13C2C60EF4D3D0E]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36351: ADDREPLICA failed to create replica
at __randomizedtesting.SeedInfo.seed([496813BA41B150F6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)
at 
org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCollectionInOneInstance$1(BasicDistributedZkTest.java:656)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:835)




Build Log:
[...truncated 2061 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J0-20190410_163401_32815961866370303751178.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 5 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J1-20190410_163401_3282734624988175894485.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 10 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J2-20190410_163401_32815107965082441154529.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 304 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/test-framework/test/temp/junit4-J0-20190410_165647_9937943755769406497059.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/test-framework/test/temp/junit4-J1-20190410_165647_99311996816534750593449.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/test-framework/test/temp/junit4-J2-20190410_165647_9944216654396189639920.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 1080 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20190410_170030_6241910603199414205424.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 

[jira] [Updated] (SOLR-12666) Support multiple AuthenticationPlugin's simultaneoulsy

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl updated SOLR-12666:
---
Description: 
Solr is getting support for more authentication plugins year by year, and 
customers have developed their own in-house plugins as well.

At the same time we see more and more JIRAs to add *BasicAuth* support for 
various clients and use cases, such as SOLR-12584 (Solr Exporter), SOLR-9779 
(Streaming expressions), SOLR-11356 (ConcurrentUpdateSolrClient), SOLR-8213 
(JDBC), SOLR-12583 (Subquery docTransformer) and SOLR-10322 (Streaming 
expression daemon), 
[SOLR-12860|https://issues.apache.org/jira/browse/SOLR-12860] (metrics 
history), SOLR-11759 (DocExpirationUpdateProcessor), SOLR-11959 (CDCR), 
SOLR-12359 (LIR) and probably more. Some of these may be bugs that can be fixed 
with PKI though...

Currently the framework supports *only one active Auth method* (except PKI 
which is special). Which means that if you use something else than BasicAuth, 
you're lucky if you get any of the above features to work with your cluster. 
Even the AdminUI only supports BasicAuth (implicit via browser).

I think the solution is to allow more than one auth plugin to be active at the 
same time, allowing people to use their custom fancy auth which is tightly 
integrated with their environment, and at the same time activate BasicAuth for 
use with other clients that do not support the primary auth method.

  was:
Solr is getting support for more authentication plugins year by year, and 
customers have developed their own in-house plugins as well.

At the same time we see more and more JIRAs to add *BasicAuth* support for 
various clients and use cases, such as SOLR-12584 (Solr Exporter), SOLR-9779 
(Streaming expressions), SOLR-11356 (ConcurrentUpdateSolrClient), SOLR-8213 
(JDBC), SOLR-12583 (Subquery docTransformer) and SOLR-10322 (Streaming 
expression daemon), SOLR-12526 (metrics history), SOLR-11759 
(DocExpirationUpdateProcessor), SOLR-11959 (CDCR), SOLR-12359 (LIR) and 
probably more. Some of these may be bugs that can be fixed with PKI though...

Currently the framework supports *only one active Auth method* (except PKI 
which is special). Which means that if you use something else than BasicAuth, 
you're lucky if you get any of the above features to work with your cluster. 
Even the AdminUI only supports BasicAuth (implicit via browser).

I think the solution is to allow more than one auth plugin to be active at the 
same time, allowing people to use their custom fancy auth which is tightly 
integrated with their environment, and at the same time activate BasicAuth for 
use with other clients that do not support the primary auth method.


> Support multiple AuthenticationPlugin's simultaneoulsy
> --
>
> Key: SOLR-12666
> URL: https://issues.apache.org/jira/browse/SOLR-12666
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication, security
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: authentication
>
> Solr is getting support for more authentication plugins year by year, and 
> customers have developed their own in-house plugins as well.
> At the same time we see more and more JIRAs to add *BasicAuth* support for 
> various clients and use cases, such as SOLR-12584 (Solr Exporter), SOLR-9779 
> (Streaming expressions), SOLR-11356 (ConcurrentUpdateSolrClient), SOLR-8213 
> (JDBC), SOLR-12583 (Subquery docTransformer) and SOLR-10322 (Streaming 
> expression daemon), 
> [SOLR-12860|https://issues.apache.org/jira/browse/SOLR-12860] (metrics 
> history), SOLR-11759 (DocExpirationUpdateProcessor), SOLR-11959 (CDCR), 
> SOLR-12359 (LIR) and probably more. Some of these may be bugs that can be 
> fixed with PKI though...
> Currently the framework supports *only one active Auth method* (except PKI 
> which is special). Which means that if you use something else than BasicAuth, 
> you're lucky if you get any of the above features to work with your cluster. 
> Even the AdminUI only supports BasicAuth (implicit via browser).
> I think the solution is to allow more than one auth plugin to be active at 
> the same time, allowing people to use their custom fancy auth which is 
> tightly integrated with their environment, and at the same time activate 
> BasicAuth for use with other clients that do not support the primary auth 
> method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8906) Make transient core cache pluggable.

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814782#comment-16814782
 ] 

Erick Erickson commented on SOLR-8906:
--

Yeah, saw that just now. Commented on LUCENE-8738, but it looks good to me.

 

And a big thanks for everyone's work on moving to Java 11

> Make transient core cache pluggable.
> 
>
> Key: SOLR-8906
> URL: https://issues.apache.org/jira/browse/SOLR-8906
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 6.6, 7.0
>
> Attachments: SOLR-8906.patch, SOLR-8906.patch, SOLR-8906.patch, 
> SOLR-8906.patch, SOLR-8906.patch
>
>
> The current Lazy Core stuff is pretty deeply intertwined in CoreContainer. 
> Adding and removing active cores is based on a simple LRU mechanism, but 
> keeping the right cores in the right internal structures involves a lot of 
> attention to locking various objects to update internal structures. This 
> makes it difficult/dangerous to use any other caching algorithms.
> Any single age-out algorithm will have non-optimal access patterns, so making 
> this pluggable would allow better algorithms to be substituted in those cases.
> If we ever extend transient cores to SolrCloud, we need to have load/unload 
> decisions that are cloud-aware rather then entirely local so in that sense 
> this is would lay some groundwork if we ever want to go there.
> So I'm going to try to hack together a PoC. Any ideas on the most sensible 
> pattern for this gratefully received.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814781#comment-16814781
 ] 

Erick Erickson commented on LUCENE-8738:


LGTM. The point of that code was to allow any custom transient cache 
implementation to "reach back" into CoreContainer to notify when a core should 
be closed. There's a bunch of synchronization that needs to be done for that 
process and it looks like when people go to 9.0 they'll have to model on these 
changes, which should be straightforward.

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814754#comment-16814754
 ] 

Uwe Schindler commented on LUCENE-8738:
---

The code seems to be updated like described here: 
https://www.baeldung.com/java-observer-pattern

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13391) Add variance and standard deviation stream evaluators

[Nazerke Seidan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814745#comment-16814745
 ] 

Nazerke Seidan commented on SOLR-13391:
---

[~joel.bernstein], I have ready code on this to the pull request. What I used 
were StatUtils.variance(data) and Math.sqrt(StatUtils.variance(data))  instead 
of StatUtils.mean(data) in the MeanEvaluator.java.

> Add variance and standard deviation stream evaluators
> -
>
> Key: SOLR-13391
> URL: https://issues.apache.org/jira/browse/SOLR-13391
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Nazerke Seidan
>Priority: Minor
>  Labels: pull-request-available
>
> It seems variance and standard deviation stream evaluators are not supported 
> by any of the solr version. For example, 
>               let(echo="m,v,sd", arr=array(1,3,3), m=mean(a), v=var(a), 
> sd=stddev(a))
> So far, only the mean function is implemented. I think it is useful to have 
> var and sttdev functions separately as a stream evaluator. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13391) Add variance and standard deviation stream evaluators

[Nazerke Seidan (JIRA)]

Nazerke Seidan created SOLR-13391:
-

 Summary: Add variance and standard deviation stream evaluators
 Key: SOLR-13391
 URL: https://issues.apache.org/jira/browse/SOLR-13391
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: streaming expressions
Reporter: Nazerke Seidan


It seems variance and standard deviation stream evaluators are not supported by 
any of the solr version. For example, 

              let(echo="m,v,sd", arr=array(1,3,3), m=mean(a), v=var(a), 
sd=stddev(a))

So far, only the mean function is implemented. I think it is useful to have var 
and sttdev functions separately as a stream evaluator. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13262) Implement collection RENAME command

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814741#comment-16814741
 ] 

ASF subversion and git services commented on SOLR-13262:


Commit f83098752c5340f352d146460fd8fc1caa03301c in lucene-solr's branch 
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f830987 ]

SOLR-13262: Add collection RENAME command and support using aliases in most 
collection admin commands.


> Implement collection RENAME command
> ---
>
> Key: SOLR-13262
> URL: https://issues.apache.org/jira/browse/SOLR-13262
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, master (9.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13262.patch, SOLR-13262.patch, SOLR-13262.patch
>
>
> There's no RENAME collection command, which makes it unnecessarily difficult 
> to manage long-term collection life-cycles.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13390) Provide Query Elevation Component by default

[Erik Hatcher (JIRA)]

Erik Hatcher created SOLR-13390:
---

 Summary: Provide Query Elevation Component by default
 Key: SOLR-13390
 URL: https://issues.apache.org/jira/browse/SOLR-13390
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erik Hatcher


Like other components, like highlighting and faceting, it'd be useful to have 
this work out of the box by just enabling it on the request.   Currently the 
component needs to be added to `/select` and an empty elevate.xml file needs to 
be added to the config - a bit unnecessarily arduous.

Let's add the component to `/select` and modify the component to be happy with 
or without an elevate.xml (since id's can be sent on the request to elevate, so 
fixed config isn't needed either).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13336) maxBooleanClauses ignored; can result in exponential expansion of naive queries

[Michael Gibney (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814727#comment-16814727
 ] 

Michael Gibney commented on SOLR-13336:
---

+1, the patch looks good to me; thanks!

> maxBooleanClauses ignored; can result in exponential expansion of naive 
> queries
> ---
>
> Key: SOLR-13336
> URL: https://issues.apache.org/jira/browse/SOLR-13336
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 7.0, 7.6, master (9.0)
>Reporter: Michael Gibney
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13336.patch, SOLR-13336.patch
>
>
> Since SOLR-10921 it appears that Solr always sets 
> {{BooleanQuery.maxClauseCount}} (at the Lucene level) to 
> {{Integer.MAX_VALUE-1}}. I assume this is because Solr parses 
> {{maxBooleanClauses}} out of the config and applies it externally.
> In any case, when used as part of 
> {{lucene.util.QueryBuilder.analyzeGraphPhrase}} (and possibly other places?), 
> the Lucene code checks internally against only the static {{maxClauseCount}} 
> variable (permanently set to {{Integer.MAX_VALUE-1}} in the context of Solr).
> Thus in at least one case ({{analyzeGraphPhrase()}}, but possibly others?), 
> {{maxBooleanClauses}} is having no effect. I'm pretty sure this is what's 
> underlying the [issue reported here as being related to Solr 
> 7.6|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201902.mbox/%3CCAF%3DheHE6-MOtn2XRbEg7%3D1tpNEGtE8GaChnOhFLPeJzpF18SGA%40mail.gmail.com%3E].
> To summarize, users are definitely susceptible (to varying degrees of likely 
> severity, assuming no actual _malicious_ attack) if:
>  # Running Solr >= 7.6.0
>  # Using edismax with "ps" param set to >0
>  # Query-time analysis chain is _at all_ capable of producing graphs (e.g., 
> WordDelimiterGraphFilter, SynonymGraphFilter that has corresponding synonyms 
> with varying token lengths.
> Users are _particularly_ vulnerable in practice if they have query-time 
> {{WordDelimiterGraphFilter}} configured with {{preserveOriginal=true}}.
> To clarify, Lucene/Solr 7.6 didn't exactly _introduce_ the issue; it only 
> increased the likelihood of problems manifesting (as a result of 
> LUCENE-8531). Notably, the "enumerated strings" approach to graph phrase 
> query (reintroduced by LUCENE-8531) was previously in place pre-6.5 – at 
> which point it could rely on default Lucene-level {{maxClauseCount}} failsafe 
> (removed as of 7.0). This explains the odd "Affects versions" => 
> maxBooleanClauses was disabled at the Lucene level (in Solr contexts) 
> starting with version 7.0, but the change became more likely to manifest 
> problems for users as of 7.6.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-13389) rectify discrepencies in socket (and connect) timeout values used throughout the code and tests - probably helping to reduce TimeoutExceptions in tests

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814722#comment-16814722
 ] 

Mark Miller edited comment on SOLR-13389 at 4/10/19 5:57 PM:
-

Because no test should have a call that takes 10 minutes like is valid in the 
wild.

We raise all the timeouts so high in tests, tests start taking forever to fail 
when they fail or even to pass because failure is expected and takes forever.

I don't see any reason tests and production should have the same timeouts. 
Tests should have timeouts just large enough to work without false fails.

When our test timeouts are so long and loose, it simply hides slow and bad 
stuff and has for a long time.

I do agree that we should have way fewer places this stuff is set, but I also 
strongly believe there should be production and test defaults when it comes to 
timeouts. We don't want any 10 minute timeout in a test unless its a crazy test 
and a developer explicitly allows that.


was (Author: markrmil...@gmail.com):
Because no test should have a call that takes 10 minutes like it valid in the 
while.

We raise all the timeouts so high in tests, tests start taking forever to fail 
when they fail or even to pass because failure is expected and takes forever.

I don't see any reason tests and production should have the same timeouts. 
Tests should have timeouts just large enough to work without false fails.

When our test timeouts are so long and loose, it simply hides slow and bad 
stuff and has for a long time.

I do agree that we should have way fewer places this stuff is set, but I also 
strongly believe there should be production and test defaults when it comes to 
timeouts. We don't want any 10 minute timeout in a test unless its a crazy test 
and a developer explicitly allows that.

> rectify discrepencies in socket (and connect) timeout values used throughout 
> the code and tests - probably helping to reduce TimeoutExceptions in tests
> ---
>
> Key: SOLR-13389
> URL: https://issues.apache.org/jira/browse/SOLR-13389
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
>
> While looking into some jenkins test failures caused by distributed requests 
> that timeout, i realized that the "socket timeout" aka "idle timeout" aka 
> "SO_TIMEOUT" values used in various places in the code & sample configs can 
> vary significantly, and in the case of *test* configs/code can differ from 
> the default / production configs by an order of magnitude.
> I think we should consider rectifying some of the various places/ways that 
> different values are sprinkled through out the code to reduce the number of 
> (different) places we have magic constants.  I believe a large number of 
> jenkins test failures we currently see due to timeout exceptions are simply 
> because tests (or test configs) override sensible defaults w/values that are 
> too low to be useful.
> (NOTE: all of these problems / discrepancies also apply to "connect timeout" 
> which should probably be addressed at the same time, but for now i'm focusing 
> on the "socket timeout" since it seems to be the bigger problem in jenkins 
> failures -- if we reach consensus on standardizing some values across the 
> board the same approach can be made to connect timeouts at the same time)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13389) rectify discrepencies in socket (and connect) timeout values used throughout the code and tests - probably helping to reduce TimeoutExceptions in tests

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814722#comment-16814722
 ] 

Mark Miller commented on SOLR-13389:


Because no test should have a call that takes 10 minutes like it valid in the 
while.

We raise all the timeouts so high in tests, tests start taking forever to fail 
when they fail or even to pass because failure is expected and takes forever.

I don't see any reason tests and production should have the same timeouts. 
Tests should have timeouts just large enough to work without false fails.

When our test timeouts are so long and loose, it simply hides slow and bad 
stuff and has for a long time.

I do agree that we should have way fewer places this stuff is set, but I also 
strongly believe there should be production and test defaults when it comes to 
timeouts. We don't want any 10 minute timeout in a test unless its a crazy test 
and a developer explicitly allows that.

> rectify discrepencies in socket (and connect) timeout values used throughout 
> the code and tests - probably helping to reduce TimeoutExceptions in tests
> ---
>
> Key: SOLR-13389
> URL: https://issues.apache.org/jira/browse/SOLR-13389
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
>
> While looking into some jenkins test failures caused by distributed requests 
> that timeout, i realized that the "socket timeout" aka "idle timeout" aka 
> "SO_TIMEOUT" values used in various places in the code & sample configs can 
> vary significantly, and in the case of *test* configs/code can differ from 
> the default / production configs by an order of magnitude.
> I think we should consider rectifying some of the various places/ways that 
> different values are sprinkled through out the code to reduce the number of 
> (different) places we have magic constants.  I believe a large number of 
> jenkins test failures we currently see due to timeout exceptions are simply 
> because tests (or test configs) override sensible defaults w/values that are 
> too low to be useful.
> (NOTE: all of these problems / discrepancies also apply to "connect timeout" 
> which should probably be addressed at the same time, but for now i'm focusing 
> on the "socket timeout" since it seems to be the bigger problem in jenkins 
> failures -- if we reach consensus on standardizing some values across the 
> board the same approach can be made to connect timeouts at the same time)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13389) rectify discrepencies in socket (and connect) timeout values used throughout the code and tests - probably helping to reduce TimeoutExceptions in tests

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814714#comment-16814714
 ] 

Hoss Man commented on SOLR-13389:
-

First off, some notes on what I found when I went digging...
 * {{SolrClientBuilder}} has a hardcoded default value of {{protected Integer 
socketTimeoutMillis = 12}} ... aka: *2 minutes*
 ** this serves as the default value for all of the SolrClient impls with 
Builders that subclass it: HttpSolrClient, ConcurrentUpdateSolrClient, 
LBHttpSolrClient, CloudSolrClient.
 ** *BUT* aproximately half of the places in solr/core that use a 
SolrClient.Builder, override this default via {{withSocketTimeout(...)}}
 *** in some cases hardcoded values are used that vary from as little as *1 
second* (RecoveryStrategy) to as much as *2 minutes* 
(OverseerCollectionMessageHandler, SyncStrategy & IndexFetcher)

 * {{HttpClientUtil}} defines a {{public static final int DEFAULT_SO_TIMEOUT = 
60}} ... aka: *10 minutes*
 ** this constant is used in a few {{HttpClientUtil}} helper methods:
 *** hardcoded value when {{HttpClientUtil.createDefaultRequestConfigBuilder()}}
 *** default when using {{HttpClientUtil.createClient(SolrParams...)}}
 ** this constant is also used as the default value for {{Http2SolrClient}}
 ** This efective value (60ms) is also specified as the "soft coded" 
default in the solr.xml for both intranode related options:
 *** {{}}: {{${socketTimeout:60}}}
 *** {{}}: {{${distribUpdateSoTimeout:60}}}
 *** this constant is also used as the "hard coded" default in the 
corresponding java code if solr.xml doesn't contain those optional settings

 * In our _test_ solr.xml files, the "soft coded" default 
socketTimeout/distribUpdateSoTimeout values vary significantly from the version 
of solr.xml we give to users...
 ** {{test-files/solr/solr.xml}}
 *** {{socketTimeout}} = *15 seconds*
 *** {{distribUpdateSoTimeout}} = *30 seconds*
 *** NOTE: this is the file used by most "legacy" distributed/zk tests
 ** {{test-files/solr/solr-solrreporter.xml}} & {{.../solr-jmxreporter.xml}} & 
{{.../solr-trackingshardhandler.xml}} & {{MiniSolrCloudCluster}} 's inline 
{{DEFAULT_CLOUD_SOLR_XML}}
 *** {{socketTimeout}} = *90 seconds*
 *** {{distribUpdateSoTimeout}} = *340 seconds* (5 minutes 40 seconds ?!?!)
 ** {{test-files/solr/solr-50-all.xml}} ... only used for config parsing 
tests...
 *** {{socketTimeout}} = *100 ms*
 *** {{distribUpdateSoTimeout}} = *33 ms*
 ** {{test-files/solr/solr-stress-new.xml}} ... only used for some Zk file 
management tests??? ...
 *** {{socketTimeout}} = *90 seconds*
 *** {{distribUpdateSoTimeout}} ... left to default
 ** In ~10 test (base) classes these "soft coded" defaults are overridden via 
{{System.setProperty()}} using values varying from as little as *3 seconds* 
(PeerSyncReplicationTest) to a max of *90 seconds* (HdfsTestUtil)
 *** I suspect – but have not dug deep into the archives to verify – that in 
most cases these were probably adhoc attempts to overcome timeout related 
failures seen in the wild, but since then the "global defaults" have been 
changed to be much higher (in some cases higher then what the individual tests 
hardcode)

 * In our test _code_, tests that use {{SolrClients}} to communicate with solr 
use a variety of socket timeouts...
 ** a handful of tests construct the SolrClient (Builders) themselves, and use 
values ranging from *30 seconds* to *90 seconds*
 ** tests using {{MiniSolrCloudCluster.getSolrClient()}} get a hardcoded *90 
seconds*
 ** tests using the various 
{{SolrTestCaseJ4.get(Http|LBHttp|Cloud|ConcurrentUpdate|CloudHttp2)SolrClient(...)}}
 methods get the default from the corrisponding Builder ... unless they 
override it...
 *** ...which a handful of tests do, frequently w/o any clear pattern or 
obvious reasons (or comments) and usually using values _lower_ then the default 
behavior of the client
 *** I suspect – but have not dug deep into the archives to verify – that in 
most cases these were probably adhoc attempts to overcome timeout related 
failures seen in the wild, but since then the "global defaults" have been 
changed to be much higher (in some cases higher then what the individual tests 
hardcode)


w/o (or at least: "before") bikesheeding over the specific numeric values to be 
used (which for now i'll just refer to as {{$VARIABLES}}, i'd like to 
propose/discuss whether it makes sense to establish in principle that the 
following statements should hold true:
 # All SolrClient (both HTTP1 and HTTP2) iplementations should use the same 
default unless the user explicitly configures (ie: 
{{$CLIENT_SOCKET_TIMEOUT_DEFAULT}})
 # the hardcoded and softcoded default values specified in solr.xml for 
intranode communication should be *at least* as big as the SolrClient default 
(ie: {{$INTRANODE_SOCKET_TIMEOUT_DEFAULT >= $CLIENT_SOCKET_TIMEOUT_DEFAULT}} )
 # the ~25 or so places in 

[jira] [Commented] (SOLR-13389) rectify discrepencies in socket (and connect) timeout values used throughout the code and tests - probably helping to reduce TimeoutExceptions in tests

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814712#comment-16814712
 ] 

Kevin Risden commented on SOLR-13389:
-

Big plus one from me. I know I looked at this a bit as part of HDFS tests. I am 
99% sure what I put is not correct but it fixed some of the HDFS tests.

https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java#L115

This is just conjecture, but I think there might be some weirdness with the 
HTTP2 handling of sockets compared to HTTP 1.1. I just have that hunch based on 
some of the errors I've seen.

> rectify discrepencies in socket (and connect) timeout values used throughout 
> the code and tests - probably helping to reduce TimeoutExceptions in tests
> ---
>
> Key: SOLR-13389
> URL: https://issues.apache.org/jira/browse/SOLR-13389
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
>
> While looking into some jenkins test failures caused by distributed requests 
> that timeout, i realized that the "socket timeout" aka "idle timeout" aka 
> "SO_TIMEOUT" values used in various places in the code & sample configs can 
> vary significantly, and in the case of *test* configs/code can differ from 
> the default / production configs by an order of magnitude.
> I think we should consider rectifying some of the various places/ways that 
> different values are sprinkled through out the code to reduce the number of 
> (different) places we have magic constants.  I believe a large number of 
> jenkins test failures we currently see due to timeout exceptions are simply 
> because tests (or test configs) override sensible defaults w/values that are 
> too low to be useful.
> (NOTE: all of these problems / discrepancies also apply to "connect timeout" 
> which should probably be addressed at the same time, but for now i'm focusing 
> on the "socket timeout" since it seems to be the bigger problem in jenkins 
> failures -- if we reach consensus on standardizing some values across the 
> board the same approach can be made to connect timeouts at the same time)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13389) rectify discrepencies in socket (and connect) timeout values used throughout the code and tests - probably helping to reduce TimeoutExceptions in tests

[Hoss Man (JIRA)]

Hoss Man created SOLR-13389:
---

 Summary: rectify discrepencies in socket (and connect) timeout 
values used throughout the code and tests - probably helping to reduce 
TimeoutExceptions in tests
 Key: SOLR-13389
 URL: https://issues.apache.org/jira/browse/SOLR-13389
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man



While looking into some jenkins test failures caused by distributed requests 
that timeout, i realized that the "socket timeout" aka "idle timeout" aka 
"SO_TIMEOUT" values used in various places in the code & sample configs can 
vary significantly, and in the case of *test* configs/code can differ from the 
default / production configs by an order of magnitude.

I think we should consider rectifying some of the various places/ways that 
different values are sprinkled through out the code to reduce the number of 
(different) places we have magic constants.  I believe a large number of 
jenkins test failures we currently see due to timeout exceptions are simply 
because tests (or test configs) override sensible defaults w/values that are 
too low to be useful.

(NOTE: all of these problems / discrepancies also apply to "connect timeout" 
which should probably be addressed at the same time, but for now i'm focusing 
on the "socket timeout" since it seems to be the bigger problem in jenkins 
failures -- if we reach consensus on standardizing some values across the board 
the same approach can be made to connect timeouts at the same time)




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814705#comment-16814705
 ] 

Yonik Seeley commented on LUCENE-8738:
--

bq. I think the Observable/Observer is uncritical.

I agree.  Pluggable transient core cache is super-expert level (almost more 
like internals) and if anyone actually uses it they can adapt when upgrading.
I did a quick scan of the related changes and they look fine.

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814664#comment-16814664
 ] 

Uwe Schindler edited comment on LUCENE-8738 at 4/10/19 5:31 PM:


I think the Observable/Observer is uncritical. But I'd also ask the 
specialists, especially [~ysee...@gmail.com].


was (Author: thetaphi):
I think the Observable/Observer is uncritical. It exists in Solr since early 
beginning, but for no reason. But I'd also ask the specialists, especially 
[~ysee...@gmail.com].

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8906) Make transient core cache pluggable.

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814692#comment-16814692
 ] 

Uwe Schindler commented on SOLR-8906:
-

The Observable stuff is deprecated in Java 11, so we stumbled on this issue in 
LUCENE-8738. Can you check if the changes in LUCENE-8738 are fine?

> Make transient core cache pluggable.
> 
>
> Key: SOLR-8906
> URL: https://issues.apache.org/jira/browse/SOLR-8906
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 6.6, 7.0
>
> Attachments: SOLR-8906.patch, SOLR-8906.patch, SOLR-8906.patch, 
> SOLR-8906.patch, SOLR-8906.patch
>
>
> The current Lazy Core stuff is pretty deeply intertwined in CoreContainer. 
> Adding and removing active cores is based on a simple LRU mechanism, but 
> keeping the right cores in the right internal structures involves a lot of 
> attention to locking various objects to update internal structures. This 
> makes it difficult/dangerous to use any other caching algorithms.
> Any single age-out algorithm will have non-optimal access patterns, so making 
> this pluggable would allow better algorithms to be substituted in those cases.
> If we ever extend transient cores to SolrCloud, we need to have load/unload 
> decisions that are cloud-aware rather then entirely local so in that sense 
> this is would lay some groundwork if we ever want to go there.
> So I'm going to try to hack together a PoC. Any ideas on the most sensible 
> pattern for this gratefully received.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814684#comment-16814684
 ] 

Uwe Schindler commented on LUCENE-8738:
---

I checked the Observer/Observable stuff, it's related to SOLR-8906. I will put 
[~erickerickson] into the loop, he may know more. It was not Yonik.

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Using util.Optional instead of a raw null?

[Diego Ceccarelli (BLOOMBERG/ LONDON)]

Hi *, 
I have a general question about using Optional instead of a raw null:
I have noticed that some functions in Solr are dealing with input parameters 
that might be null, these parameters might be wrapped into Optional - to avoid 
forgetting that they might be nulls and also to make clear that they are.. 
optional. 

For example in marshalOrUnmarshalSortValue 
https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/ShardResultTransformerUtils.java#L37

both originalSortValue and schemaField are optional, and we might declare them 
Optional. 
any opinion? 

Cheers,
Diego

[jira] [Comment Edited] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814664#comment-16814664
 ] 

Uwe Schindler edited comment on LUCENE-8738 at 4/10/19 5:05 PM:


I think the Observable/Observer is uncritical. It exists in Solr since early 
beginning, but for no reason. But I'd also ask the specialists, especially 
[~ysee...@gmail.com].


was (Author: thetaphi):
I think the Observable/Observer is uncritical. It exists in Solr since early 
beginning, but for no reason. But I'd also ask the specialists, especially 
[~yo...@apache.org].

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_172) - Build # 7880 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7880/
Java: 32bit/jdk1.8.0_172 -client -XX:+UseSerialGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudHttp2SolrClientTest

Error Message:
ObjectTracker found 3 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:99)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:779)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:976)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1245)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1155)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:509)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:351) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:422) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$13(ReplicationHandler.java:1191)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1063)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1245)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1155)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)   expected null, but 
was:(SolrCore.java:976)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1245)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1155)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814664#comment-16814664
 ] 

Uwe Schindler commented on LUCENE-8738:
---

I think the Observable/Observer is uncritical. It exists in Solr since early 
beginning, but for no reason. But I'd also ask the specialists, especially 
[~yo...@apache.org].

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814653#comment-16814653
 ] 

Uwe Schindler commented on LUCENE-8738:
---

OK, fixed SOLR-13388 in master/8.x

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler resolved SOLR-13388.
--
Resolution: Fixed

> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13388.patch
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814651#comment-16814651
 ] 

ASF subversion and git services commented on LUCENE-8738:
-

Commit 5d778dee4131bd55a483eaeb9e040d771a54020d in lucene-solr's branch 
refs/heads/jira/LUCENE-8738 from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5d778de ]

Merge branch 'master' of https://gitbox.apache.org/repos/asf/lucene-solr into 
jira/LUCENE-8738


> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814649#comment-16814649
 ] 

ASF subversion and git services commented on SOLR-13388:


Commit eafe42f090b4247ec876753c4e00ba68f5ecd3c1 in lucene-solr's branch 
refs/heads/jira/LUCENE-8738 from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=eafe42f ]

SOLR-13388: Fix FileExchangeRateProvider to be a public class, as it appears in 
schema.xml


> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13388.patch
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13262) Implement collection RENAME command

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814650#comment-16814650
 ] 

ASF subversion and git services commented on SOLR-13262:


Commit 02c4503f8c122361c4c99e3776cfdcef15b859bd in lucene-solr's branch 
refs/heads/jira/LUCENE-8738 from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=02c4503 ]

SOLR-13262: Add collection RENAME command and support using aliases in most 
collection admin commands.


> Implement collection RENAME command
> ---
>
> Key: SOLR-13262
> URL: https://issues.apache.org/jira/browse/SOLR-13262
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, master (9.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13262.patch, SOLR-13262.patch, SOLR-13262.patch
>
>
> There's no RENAME collection command, which makes it unnecessarily difficult 
> to manage long-term collection life-cycles.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814644#comment-16814644
 ] 

ASF subversion and git services commented on SOLR-13388:


Commit 4fe1f410f4c8ce83538e555a69abf97929946f31 in lucene-solr's branch 
refs/heads/branch_8x from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4fe1f41 ]

SOLR-13388: Fix FileExchangeRateProvider to be a public class, as it appears in 
schema.xml


> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13388.patch
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13262) Implement collection RENAME command

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814646#comment-16814646
 ] 

ASF subversion and git services commented on SOLR-13262:


Commit 02c4503f8c122361c4c99e3776cfdcef15b859bd in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=02c4503 ]

SOLR-13262: Add collection RENAME command and support using aliases in most 
collection admin commands.


> Implement collection RENAME command
> ---
>
> Key: SOLR-13262
> URL: https://issues.apache.org/jira/browse/SOLR-13262
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, master (9.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13262.patch, SOLR-13262.patch, SOLR-13262.patch
>
>
> There's no RENAME collection command, which makes it unnecessarily difficult 
> to manage long-term collection life-cycles.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814641#comment-16814641
 ] 

ASF subversion and git services commented on SOLR-13388:


Commit eafe42f090b4247ec876753c4e00ba68f5ecd3c1 in lucene-solr's branch 
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=eafe42f ]

SOLR-13388: Fix FileExchangeRateProvider to be a public class, as it appears in 
schema.xml


> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13388.patch
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814639#comment-16814639
 ] 

Uwe Schindler commented on SOLR-13388:
--

No need to test this before commit, as it will fail anyways (no new tests for 
this).

> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13388.patch
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-master - Build # 3259 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3259/

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest

Error Message:
ObjectTracker found 2 object(s) that were not released!!! [SolrZkClient, 
ZkStateReader] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.cloud.SolrZkClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:203)  
at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:126)  at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)  at 
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:309)  at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
  at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.connect(BaseCloudSolrClient.java:329)
  at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:773)
  at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:942)
  at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:763)
  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)  at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)  at 
org.apache.solr.client.solrj.impl.SolrClientCloudManager.request(SolrClientCloudManager.java:115)
  at 
org.apache.solr.cloud.autoscaling.SystemLogListener.onEvent(SystemLogListener.java:126)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:836)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:803)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$add$4(ScheduledTriggers.java:297)
  at 
org.apache.solr.cloud.autoscaling.NodeLostTrigger.run(NodeLostTrigger.java:185) 
 at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerWrapper.run(ScheduledTriggers.java:633)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.cloud.ZkStateReader  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:331)  
at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
  at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.connect(BaseCloudSolrClient.java:329)
  at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:773)
  at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:942)
  at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:763)
  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)  at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)  at 
org.apache.solr.client.solrj.impl.SolrClientCloudManager.request(SolrClientCloudManager.java:115)
  at 
org.apache.solr.cloud.autoscaling.SystemLogListener.onEvent(SystemLogListener.java:126)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:836)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:803)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$add$4(ScheduledTriggers.java:297)
  at 
org.apache.solr.cloud.autoscaling.NodeLostTrigger.run(NodeLostTrigger.java:185) 
 at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerWrapper.run(ScheduledTriggers.java:633)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 

[jira] [Comment Edited] (SOLR-13386) Remove race in OverseerTaskQueue#remove that can result in the Overseer causing a Zookeeper call spin spike.

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814630#comment-16814630
 ] 

Tomás Fernández Löbbe edited comment on SOLR-13386 at 4/10/19 4:44 PM:
---

Good catch
bq. and treat it the same as exists returning false
Maybe we can just skip the "exists" call? The NoNodeException should not be the 
normal case. I mean, something like:
{code:java}
try {
zookeeper.setData(responsePath, event.getBytes(), true);
} catch (NoNodeException e) {
  log.info("Response path doesn't exist...");
}
{code}


was (Author: tomasflobbe):
Good catch
bq. and treat it the same as exists returning false
Maybe we can just skip the "exists" call? The NoNodeException should not be the 
normal case.

> Remove race in OverseerTaskQueue#remove that can result in the Overseer 
> causing a Zookeeper call spin spike.
> 
>
> Key: SOLR-13386
> URL: https://issues.apache.org/jira/browse/SOLR-13386
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: 7.7.2, 8.1
>
>
> If the data call hits NoNodeException, it will throw and the Overseer work 
> queue processor will catch it and loop and repeat, which causes major zk 
> getData / NoNode call traffic or other such things.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13386) Remove race in OverseerTaskQueue#remove that can result in the Overseer causing a Zookeeper call spin spike.

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814630#comment-16814630
 ] 

Tomás Fernández Löbbe commented on SOLR-13386:
--

Good catch
bq. and treat it the same as exists returning false
Maybe we can just skip the "exists" call? The NoNodeException should not be the 
normal case.

> Remove race in OverseerTaskQueue#remove that can result in the Overseer 
> causing a Zookeeper call spin spike.
> 
>
> Key: SOLR-13386
> URL: https://issues.apache.org/jira/browse/SOLR-13386
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: 7.7.2, 8.1
>
>
> If the data call hits NoNodeException, it will throw and the Overseer work 
> queue processor will catch it and loop and repeat, which causes major zk 
> getData / NoNode call traffic or other such things.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814628#comment-16814628
 ] 

Uwe Schindler commented on SOLR-13388:
--

Interestingly, the other ExchangeRateProvider was public, so this was an 
oversight. There was a reason why Class#newInstance() was deprecated!

> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13388.patch
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814626#comment-16814626
 ] 

Uwe Schindler commented on SOLR-13388:
--

Simple patch: [^SOLR-13388.patch] 

> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13388.patch
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13386) Remove race in OverseerTaskQueue#remove that can result in the Overseer causing a Zookeeper call spin spike.

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814624#comment-16814624
 ] 

Mike Drob commented on SOLR-13386:
--

I see similar pattern in {{ClusterProperties}} and {{CollectionProperties}} 
where we catch {{KeeperException.NodeExistsException}} but that probably needs 
to be {{NoNodeException}}?


> Remove race in OverseerTaskQueue#remove that can result in the Overseer 
> causing a Zookeeper call spin spike.
> 
>
> Key: SOLR-13386
> URL: https://issues.apache.org/jira/browse/SOLR-13386
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: 7.7.2, 8.1
>
>
> If the data call hits NoNodeException, it will throw and the Overseer work 
> queue processor will catch it and loop and repeat, which causes major zk 
> getData / NoNode call traffic or other such things.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated SOLR-13388:
-
Attachment: SOLR-13388.patch

> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13388.patch
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler reassigned SOLR-13388:


Assignee: Uwe Schindler

> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated SOLR-13388:
-
Affects Version/s: 8.0

> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 8.0
>Reporter: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated SOLR-13388:
-
Fix Version/s: master (9.0)
   8.1

> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Uwe Schindler
>Priority: Major
> Fix For: 8.1, master (9.0)
>
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated SOLR-13388:
-
Description: 
While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
failing becase FileExchangeRateProvider is not a public class. Reason for this:

In Java 11, Class#newInstance is deprecated, as it does not work correctly with 
Exceptions. The suggested replacement is to use getDeclaredConctructor(). But 
we decided to use getConstructor(), as all dynamic code who instantiates a 
class, e.g., from a config file, should only do this using public APIs.

But this caused Solr to fail as some config files refer this class, which is 
"package private"! So we should fix this bug and make the class public! All 
managed-schema files are referring a package private class (as default).

In the Java-11 branch we already fixed this, but it's a bug also in Java 8. It 
just works, because the code who instantiates the class is luckily in the 
correct package.

  was:
While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
failing becase FileExchangeRateProvider is not a public class. Reason for this:

In Java 11, Class#newInstance is deprecated, as it does not work correctly with 
Exceptions. The suggested replacement is to use getDeclaredConctructor(). But 
we decided to use getConstructor(), as all dynamic code who instantiates a 
class should only do this using public APIs.

But this caused Solr to fail as some config files refer this class, which is 
"package private"! So we should fix this bug and make the class public! All 
managed-schema files are referring a package private class (as default).

In the Java-11 branch we already fixed this, but it's a bug also in Java 8. It 
just works, because the code who instantiates the class is luckily in the 
correct package.


> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Uwe Schindler
>Priority: Major
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class, e.g., from a config file, should only 
> do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated SOLR-13388:
-
Description: 
While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
failing becase FileExchangeRateProvider is not a public class. Reason for this:

In Java 11, Class#newInstance is deprecated, as it does not work correctly with 
Exceptions. The suggested replacement is to use getDeclaredConctructor(). But 
we decided to use getConstructor(), as all dynamic code who instantiates a 
class should only do this using public APIs.

But this caused Solr to fail as some config files refer this class, which is 
"package private"! So we should fix this bug and make the class public! All 
managed-schema files are referring a package private class (as default).

In the Java-11 branch we already fixed this, but it's a bug also in Java 8. It 
just works, because the code who instantiates the class is luckily in the 
correct package.

  was:
While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
failing becase FileExchangeRateProvider is not a public class. Reason for this:

In Java 11, Class#newInstance is deprecated, as it does not work correctly with 
instances. The suggested replacement is to use getDeclaredConctructor(). But we 
decided to use getConstructor(), as all dynamic code who instantiates a class 
should only do this using public APIs.

But this caused Solr to fail as some config files refer this class, which is 
"package private"! So we should fix this bug and make the class public! All 
managed-schema files are referring a package private class (as default).

In the Java-11 branch we already fixed this, but it's a bug also in Java 8. It 
just works, because the code who instantiates the class is luckily in the 
correct package.


> FileExchangeRateProvider is not a public class, but appears in config files
> ---
>
> Key: SOLR-13388
> URL: https://issues.apache.org/jira/browse/SOLR-13388
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Uwe Schindler
>Priority: Major
>
> While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
> failing becase FileExchangeRateProvider is not a public class. Reason for 
> this:
> In Java 11, Class#newInstance is deprecated, as it does not work correctly 
> with Exceptions. The suggested replacement is to use 
> getDeclaredConctructor(). But we decided to use getConstructor(), as all 
> dynamic code who instantiates a class should only do this using public APIs.
> But this caused Solr to fail as some config files refer this class, which is 
> "package private"! So we should fix this bug and make the class public! All 
> managed-schema files are referring a package private class (as default).
> In the Java-11 branch we already fixed this, but it's a bug also in Java 8. 
> It just works, because the code who instantiates the class is luckily in the 
> correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814607#comment-16814607
 ] 

Uwe Schindler commented on LUCENE-8738:
---

See SOLR-13388

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13388) FileExchangeRateProvider is not a public class, but appears in config files

[Uwe Schindler (JIRA)]

Uwe Schindler created SOLR-13388:


 Summary: FileExchangeRateProvider is not a public class, but 
appears in config files
 Key: SOLR-13388
 URL: https://issues.apache.org/jira/browse/SOLR-13388
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Schema and Analysis
Reporter: Uwe Schindler


While working on LUCENE-8738, [~jpountz] figured out that Solr tests were 
failing becase FileExchangeRateProvider is not a public class. Reason for this:

In Java 11, Class#newInstance is deprecated, as it does not work correctly with 
instances. The suggested replacement is to use getDeclaredConctructor(). But we 
decided to use getConstructor(), as all dynamic code who instantiates a class 
should only do this using public APIs.

But this caused Solr to fail as some config files refer this class, which is 
"package private"! So we should fix this bug and make the class public! All 
managed-schema files are referring a package private class (as default).

In the Java-11 branch we already fixed this, but it's a bug also in Java 8. It 
just works, because the code who instantiates the class is luckily in the 
correct package.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814597#comment-16814597
 ] 

Uwe Schindler commented on LUCENE-8738:
---

I checked the code: FileExchangeRateProvider should really be public! I'll open 
an issue for 8.x

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814591#comment-16814591
 ] 

Uwe Schindler commented on LUCENE-8738:
---

I don't see anything that needs to be done before. I had not yet tested Eclipse 
config, did you do this? For Java 11 work I have to first update my main 
Eclipse installation (ARGH). You did not write "untested" so I think you 
did it.

When we merge to master, we should do this in some coordinated way, as Apache 
Jenkins and Policeman Jenkins need update of configs. Not sure about other 
Jenkins servers around.

The FileExchangeRateProvider thing is strange, it worked before as the package 
names were somehow correct, but that's a bug anyways if it appears in some solr 
config but it's not a public class! So that's a nice find, we should at least 
backport the "public" part to 8.x - as it's a bug!


> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814577#comment-16814577
 ] 

Adrien Grand commented on LUCENE-8738:
--

[~thetaphi] Do you know what still needs to be done before merging back to 
master? When we are done, ore close to being done, I plan to send an email to 
the list to ask for some more eyes on changes that I did before merging, 
especially the Observable/Observer removal.

> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_172) - Build # 375 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/375/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 15852 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-core/test/temp/junit4-J1-20190410_144842_1433171415369002370047.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/heapdumps/java_pid13183.hprof ...
   [junit4] Heap dump file created [594213961 bytes in 3.135 secs]
   [junit4] <<< JVM J1: EOF 

[...truncated 8951 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:633: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:585: Some of the tests 
produced a heap dump, but did not fail. Maybe a suppressed OutOfMemoryError? 
Dumps created:
* java_pid13183.hprof

Total time: 81 minutes 49 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814554#comment-16814554
 ] 

ASF subversion and git services commented on LUCENE-8738:
-

Commit cfe959b81458bac06f1ad5d8161e59adb85b87b2 in lucene-solr's branch 
refs/heads/jira/LUCENE-8738 from Adrien Grand
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cfe959b ]

LUCENE-8738: Update Eclipse config.


> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814555#comment-16814555
 ] 

ASF subversion and git services commented on LUCENE-8738:
-

Commit a11c3974b9e6b80b7b566bc1cd8b08c5d1db8a6b in lucene-solr's branch 
refs/heads/jira/LUCENE-8738 from Adrien Grand
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a11c397 ]

LUCENE-8738: Update Idea configuration (untested).


> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814556#comment-16814556
 ] 

ASF subversion and git services commented on LUCENE-8738:
-

Commit 65ddd311288411e9dd56fd05e69a1a68c64a84ea in lucene-solr's branch 
refs/heads/jira/LUCENE-8738 from Adrien Grand
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=65ddd31 ]

LUCENE-8738: Use getConstructor instead of getDeclaredConstructor.

I had to make FileExchangeRateProvider public.


> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-MAVEN] Lucene-Solr-Maven-8.x #70: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-8.x/70/

No tests ran.

Build Log:
[...truncated 16779 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:672: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:226: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/lucene/build.xml:426: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/lucene/common-build.xml:2269:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/lucene/common-build.xml:1750:
 Unable to initialize POM pom.xml: Could not find the model file 
'/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/lucene/build/poms/lucene/luke/pom.xml'.
 for project unknown

Total time: 6 minutes 32 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1305 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1305/

No tests ran.

Build Log:
[...truncated 12104 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/build.xml:446:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build.xml:433:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build.xml:413:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/common-build.xml:2269:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/common-build.xml:1727:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/common-build.xml:657:
 Unable to initialize POM pom.xml: Could not find the model file 
'/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/poms/lucene/luke/pom.xml'.
 for project unknown

Total time: 5 minutes 21 seconds
Build step 'Invoke Ant' marked build as failure
Setting JDK_1_9_LATEST__HOME=/home/jenkins/tools/java/latest1.9
Setting JDK_1_9_LATEST__HOME=/home/jenkins/tools/java/latest1.9
Setting JDK_1_9_LATEST__HOME=/home/jenkins/tools/java/latest1.9
Setting JDK_1_9_LATEST__HOME=/home/jenkins/tools/java/latest1.9
Setting JDK_1_9_LATEST__HOME=/home/jenkins/tools/java/latest1.9
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting JDK_1_9_LATEST__HOME=/home/jenkins/tools/java/latest1.9
Setting JDK_1_9_LATEST__HOME=/home/jenkins/tools/java/latest1.9
Setting JDK_1_9_LATEST__HOME=/home/jenkins/tools/java/latest1.9
Setting JDK_1_9_LATEST__HOME=/home/jenkins/tools/java/latest1.9

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-8.x - Build # 113 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/113/

All tests passed

Build Log:
[...truncated 15813 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build/solr-core/test/temp/junit4-J1-20190410_135827_1826852846962750648019.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: GC overhead limit exceeded
   [junit4] Dumping heap to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/heapdumps/java_pid12846.hprof
 ...
   [junit4] Heap dump file created [698566912 bytes in 5.990 secs]
   [junit4] <<< JVM J1: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build/solr-core/test/temp/junit4-J1-20190410_135827_1826441518703113344986.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] WARN: Unhandled exception in event serialization. -> 
java.lang.OutOfMemoryError: GC overhead limit exceeded
   [junit4] at java.util.Arrays.copyOf(Arrays.java:3332)
   [junit4] at 
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
   [junit4] at 
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649)
   [junit4] at java.lang.StringBuilder.append(StringBuilder.java:202)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.AbstractEvent.toAscii(AbstractEvent.java:108)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.AbstractEvent.writeBinaryProperty(AbstractEvent.java:36)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.AppendStdErrEvent.serialize(AppendStdErrEvent.java:30)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer$2.run(Serializer.java:129)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer$2.run(Serializer.java:124)
   [junit4] at java.security.AccessController.doPrivileged(Native Method)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.flushQueue(Serializer.java:124)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.serialize(Serializer.java:98)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain$3$2.write(SlaveMain.java:498)
   [junit4] at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
   [junit4] at 
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
   [junit4] at java.io.PrintStream.flush(PrintStream.java:338)
   [junit4] at 
org.apache.lucene.util.TestRuleLimitSysouts$DelegateStream.flush(TestRuleLimitSysouts.java:189)
   [junit4] at java.io.PrintStream.write(PrintStream.java:482)
   [junit4] at 
org.apache.logging.log4j.core.util.CloseShieldOutputStream.write(CloseShieldOutputStream.java:53)
   [junit4] at 
org.apache.logging.log4j.core.appender.OutputStreamManager.writeToDestination(OutputStreamManager.java:261)
   [junit4] at 
org.apache.logging.log4j.core.appender.OutputStreamManager.flushBuffer(OutputStreamManager.java:293)
   [junit4] at 
org.apache.logging.log4j.core.appender.OutputStreamManager.flush(OutputStreamManager.java:302)
   [junit4] at 
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.jav
   [junit4] a:199)
   [junit4] at 
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:190)
   [junit4] at 
org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:181)
   [junit4] at 
org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
   [junit4] at 
org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
   [junit4] at 
org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
   [junit4] at 
org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
   [junit4] at 
org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:464)
   [junit4] at 
org.apache.logging.log4j.core.async.AsyncLoggerConfig.callAppenders(AsyncLoggerConfig.java:127)
   [junit4] at 
org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:448)
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/usr/local/asfpackages/java/jdk1.8.0_191/jre/bin/java 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/heapdumps
 -ea -esa -Dtests.prefix=tests -Dtests.seed=D8F46C67D55DD5D7 -Xmx512M 
-Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
-Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random 

[jira] [Created] (LUCENE-8762) Lucene50PostingsReader should specialize reading docs+freqs with impacts

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-8762:


 Summary: Lucene50PostingsReader should specialize reading 
docs+freqs with impacts
 Key: LUCENE-8762
 URL: https://issues.apache.org/jira/browse/LUCENE-8762
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand


Currently if you ask for impacts, we only have one implementation that is able 
to expose everything: docs, freqs, positions and offsets. In contrast, if you 
don't need impacts, we have specialization for docs+freqs, docs+freqs+positions 
and docs+freqs+positions+offsets.

Maybe we should add specialization for the docs+freqs case with impacts, which 
should be the most common case, and remove specialization for 
docs+freqs+positions when impacts are not requested?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-8761) RandomGeoPolygonTest.testCompareSmallPolygons test failure

[Ignacio Vera (JIRA)]

Ignacio Vera created LUCENE-8761:


 Summary: RandomGeoPolygonTest.testCompareSmallPolygons test failure
 Key: LUCENE-8761
 URL: https://issues.apache.org/jira/browse/LUCENE-8761
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial3d
Reporter: Ignacio Vera


Reproduce with:
{code:java}
ant test  -Dtestcase=RandomGeoPolygonTest 
-Dtests.method=testCompareSmallPolygons -Dtests.seed=5616B8AF18E73F5 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=it-IT 
-Dtests.timezone=Africa/Luanda -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8{code}
 

Output:
{code:java}
   [junit4] FAILURE 0.25s | RandomGeoPolygonTest.testCompareSmallPolygons 
{seed=[5616B8AF18E73F5:3F0F8C29D1934F55]} <<<
   [junit4]    > Throwable #1: java.lang.AssertionError: 
   [junit4]    > Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=4.0E-323, 
lon=-1.5642641387776646([X=0.0065394500758205526, Y=-1.0010974954578205, 
Z=4.0E-323])], [lat=-4.1204793742327684E-7, 
lon=-1.5642638751890106([X=0.0065397139537611325, Y=-1.0010974937339752, 
Z=-4.125089589031438E-7])], [lat=4.7042128367572116E-7, 
lon=-1.5642630821305357([X=0.006540507882610503, Y=-1.0010974885472588, 
Z=4.709476164070912E-7])], [lat=1.0079428885548814E-6, 
lon=-1.5642647153663134([X=0.006538872854363873, Y=-1.0010974992277146, 
Z=1.0090706294797576E-6])]], internalEdges={3}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=4.0E-323, 
lon=-1.5642641387776646([X=0.0065394500758205526, Y=-1.0010974954578205, 
Z=4.0E-323])], [lat=1.0079428885548814E-6, 
lon=-1.5642647153663134([X=0.006538872854363873, Y=-1.0010974992277146, 
Z=1.0090706294797576E-6])], [lat=5.018093706393593E-7, 
lon=-1.5642651810798487([X=0.006538406629710141, Y=-1.0010975022732327, 
Z=5.02370822057141E-7])]], internalEdges={0}}]}
   [junit4]    > Large polygon: GeoComplexPolygon: 
{planetmodel=PlanetModel.WGS84, number of shapes=1, address=24da76d0, 
testPoint=[lat=3.1362512108941996E-7, 
lon=-1.5642641985086745([X=0.006539390279255702, Y=-1.0010974958483772, 
Z=3.139760218082874E-7])], testPointInSet=true, shapes={ 
{[lat=5.018093706393593E-7, lon=-1.5642651810798487([X=0.006538406629710141, 
Y=-1.0010975022732327, Z=5.02370822057141E-7])], [lat=4.0E-323, 
lon=-1.5642641387776646([X=0.0065394500758205526, Y=-1.0010974954578205, 
Z=4.0E-323])], [lat=-4.1204793742327684E-7, 
lon=-1.5642638751890106([X=0.0065397139537611325, Y=-1.0010974937339752, 
Z=-4.125089589031438E-7])], [lat=4.7042128367572116E-7, 
lon=-1.5642630821305357([X=0.006540507882610503, Y=-1.0010974885472588, 
Z=4.709476164070912E-7])], [lat=1.0079428885548814E-6, 
lon=-1.5642647153663134([X=0.006538872854363873, Y=-1.0010974992277146, 
Z=1.0090706294797576E-6])]}}
   [junit4]    > Point: [lat=2.8705346198541964E-8, 
lon=7.537339947889447E-73([X=1.0011188539924787, Y=7.545773130782812E-73, 
Z=2.8737463289741695E-8])]
   [junit4]    > WKT: POLYGON((-89.62573319562668 2.263E-321,-89.62571809310927 
-2.3608607771424413E-5,-89.62567265420576 
2.6953154147745272E-5,-89.62576623172276 
5.775087350441979E-5,-89.62579291514281 2.875155905775134E-5,-89.62573319562668 
2.263E-321))
   [junit4]    > WKT: POINT(4.318577677694212E-71 1.6446951866383562E-6)
   [junit4]    > normal polygon: false
   [junit4]    > large polygon: true{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8738) Bump minimum Java version requirement to 11

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814486#comment-16814486
 ] 

ASF subversion and git services commented on LUCENE-8738:
-

Commit d13874a0da37732c90cb764b8f9165bfeb8713da in lucene-solr's branch 
refs/heads/jira/LUCENE-8738 from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d13874a ]

Merge branch 'master' of https://gitbox.apache.org/repos/asf/lucene-solr into 
jira/LUCENE-8738


> Bump minimum Java version requirement to 11
> ---
>
> Key: LUCENE-8738
> URL: https://issues.apache.org/jira/browse/LUCENE-8738
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Adrien Grand
>Priority: Minor
>  Labels: Java11
> Fix For: master (9.0)
>
>
> See vote thread for reference: https://markmail.org/message/q6ubdycqscpl43aq.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2322 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2322/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 52476 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /var/tmp/ecj291004608
 [ecj-lint] Compiling 527 source files to /var/tmp/ecj291004608
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/TestAssertions.java
 (at line 44)
 [ecj-lint] new TestTokenStream1();
 [ecj-lint] ^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/TestAssertions.java
 (at line 45)
 [ecj-lint] new TestTokenStream2();
 [ecj-lint] ^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/TestAssertions.java
 (at line 47)
 [ecj-lint] new TestTokenStream3();
 [ecj-lint] ^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
 (at line 130)
 [ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
 [ecj-lint] ^^
 [ecj-lint] Resource leak: 'writer' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
 (at line 120)
 [ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
 [ecj-lint]  
 [ecj-lint] Resource leak: 'analyzer' is never closed
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
 (at line 122)
 [ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'buffer' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
 (at line 29)
 [ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'cs' is never closed
 [ecj-lint] --
 [ecj-lint] 8. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
 (at line 34)
 [ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'cs' is never closed
 [ecj-lint] --
 [ecj-lint] 9. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
 (at line 39)
 [ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new 
StringReader("")));
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'cs' is never closed
 [ecj-lint] --
 [ecj-lint] 10. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
 (at line 44)
 [ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new 
StringReader("")));
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'cs' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 11. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
 (at line 39)
 [ecj-lint] DelegatingAnalyzerWrapper w2 = new 
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
 [ecj-lint]   ^^
 [ecj-lint] Resource leak: 'w2' is never closed
 [ecj-lint] --
 [ecj-lint] 12. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
 (at line 50)
 [ecj-lint] DelegatingAnalyzerWrapper w1 = new 
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
 [ecj-lint]   ^^
 [ecj-lint] Resource leak: 'w1' is never closed
 [ecj-lint] --
 [ecj-lint] 13. WARNING in 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
 (at line 71)
 [ecj-lint] DelegatingAnalyzerWrapper w1 = new 
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
 [ecj-lint]   ^^
 [ecj-lint] 

[GitHub] [lucene-solr] s1monw commented on issue #640: LUCENE-8671: Introduce Reader attributes

[GitBox]

s1monw commented on issue #640: LUCENE-8671: Introduce Reader attributes
URL: https://github.com/apache/lucene-solr/pull/640#issuecomment-481706543
 
 
   it's still a bit rough and misses javadocs etc. but I wanted to get the idea 
out.


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


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8752) Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' (REIWA)

[Christian Moen (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814467#comment-16814467
 ] 

Christian Moen commented on LUCENE-8752:


Thanks a lot, [~Tomoko Uchida].

> Apply a patch to kuromoji dictionary to properly handle Japanese new era '令和' 
> (REIWA)
> -
>
> Key: LUCENE-8752
> URL: https://issues.apache.org/jira/browse/LUCENE-8752
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> As of May 1st, 2019, Japanese era '元号' (Gengo) will be set to '令和' (Reiwa). 
> See this article for more details:
> [https://www.bbc.com/news/world-asia-47769566]
> Currently '令和' is splitted up to '令' and '和' by {{JapaneseTokenizer}}. It 
> should be tokenized as one word so that Japanese texts including era names 
> are searched as users expect. Because the default Kuromoji dictionary 
> (mecab-ipadic) has not been maintained since 2007, a one-line patch to the 
> source CSV file is needed for this era change.
> Era name is used in many official or formal documents in Japan, so it would 
> be desirable the search systems properly handle this without adding a user 
> dictionary or using phrase query. :)
> FYI, JDK DateTime API will support the new era (in the next updates.)
> [https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java]
> The patch is available here:
> [https://github.com/apache/lucene-solr/pull/632]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] s1monw opened a new pull request #640: LUCENE-8671: Introduce Reader attributes

[GitBox]

s1monw opened a new pull request #640: LUCENE-8671: Introduce Reader attributes
URL: https://github.com/apache/lucene-solr/pull/640
 
 
   Reader attributes allows a per IndexReader configuration of codec internals.
   For instance this allows a per reader configuration if FSTs are loaded into 
memory or are left
   on disk.


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


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-MAVEN] Lucene-Solr-Maven-master #2534: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/2534/

No tests ran.

Build Log:
[...truncated 16749 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:672: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:226: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/build.xml:426:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:2269:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:1750:
 Unable to initialize POM pom.xml: Could not find the model file 
'/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/build/poms/lucene/luke/pom.xml'.
 for project unknown

Total time: 12 minutes 48 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13285) ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during replication

[Jason Gerlowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814463#comment-16814463
 ] 

Jason Gerlowski commented on SOLR-13285:


The Atomic-update "remove" and "regexremove" instances of this problem are 
tracked on SOLR-13331, which was just resolved recently.  [~lyle_wang] or 
[~jbnas], your issues should be fixed starting in 8.1.  (If you want to double 
check me on this, please use a nightly build of Solr of build from source on 
the {{master}} or {{branch_8x}} branches and let me know if you still run into 
the issue over on SOLR-13331.

> ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during 
> replication
> -
>
> Key: SOLR-13285
> URL: https://issues.apache.org/jira/browse/SOLR-13285
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java), SolrCloud, SolrJ
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: centos 7
> solrcloud 7.7.1, 8.1.0
>Reporter: Karl Stoney
>Assignee: Noble Paul
>Priority: Major
>  Labels: newbie, replication
> Attachments: SOLR-13285.patch, SOLR-13285.patch
>
>
> Since upgrading to 7.7 (also tried 7.7.1, and 8.1.0) from 6.6.4, we're seeing 
> the following errors in the SolrCloud elected master for a given collection 
> when updates are written.  This was after a full reindex of data (fresh 
> build).
> {code:java}
> request: 
> http://solr-1.search-solr.preprod.k8.atcloud.io:80/solr/at-uk_shard1_replica_n2/update?update.distrib=FROMLEADER=http%3A%2F%2Fsolr-2.search-solr.preprod.k8.atcloud.io%3A80%2Fsolr%2Fat-uk_shard1_replica_n1%2F=javabin=2
> Remote error message: org.apache.solr.common.util.ByteArrayUtf8CharSequence 
> cannot be cast to java.lang.String
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:385)
>  ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - 
> ishan - 2019-02-23 02:39:09]
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:183)
>  ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - 
> ishan - 2019-02-23 02:39:09]
> at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>  ~[metrics-core-3.2.6.jar:3.2.6]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
>  ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - 
> ishan - 2019-02-23 02:39:09]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[?:1.8.0_191]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  ~[?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
> Following this through to the replica, you'll see:
> {code:java}
> 08:35:22.060 [qtp1540374340-20] ERROR org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ClassCastException: 
> org.apache.solr.common.util.ByteArrayUtf8CharSequence cannot be cast to 
> java.lang.String
> at 
> org.apache.solr.common.util.JavaBinCodec.readEnumFieldValue(JavaBinCodec.java:813)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:339)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:640)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:337)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.common.util.JavaBinCodec.readMapEntry(JavaBinCodec.java:819)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:341)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:295)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:333)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:298)
> at 

[JENKINS] Lucene-Artifacts-8.x - Build # 67 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Artifacts-8.x/67/

No tests ran.

Build Log:
[...truncated 12114 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-8.x/lucene/build.xml:433:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-8.x/lucene/build.xml:413:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-8.x/lucene/common-build.xml:2269:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-8.x/lucene/common-build.xml:1727:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-8.x/lucene/common-build.xml:657:
 Unable to initialize POM pom.xml: Could not find the model file 
'/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-8.x/lucene/build/poms/lucene/luke/pom.xml'.
 for project unknown

Total time: 11 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[Fast Archiver] Compressed 271.16 MB of artifacts by 30.3% relative to #66
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth

[Lorenzo (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814456#comment-16814456
 ] 

Lorenzo commented on SOLR-12860:


[~janhoy] , [~noble.paul] did you have a chance to check the patch ?

> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Critical
> Attachments: SOLR-12028_metics_handler_not_work_basic_auth.patch, 
> SOLR-12860.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then 
> uploaded the default security.json from 
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>  
> I'm seeing errors like these in the logs which would indicate that the 
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN  (MetricsHistoryHandler-12-thread-1) [   ] 
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node 
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://192.168.0.8:7574/solr: Expected mime type 
> application/octet-stream but got text/html. 
> 
> 
> Error 401 require authentication
> 
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
>     require authentication
> 
> 
>     at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) 
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
>  ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:55]
>     at 
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
>  ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:55]
>     at 
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
>  ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:55]
>     at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [?:1.8.0_112]
>     at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [?:1.8.0_112]
>     at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [?:1.8.0_112]
>     at 
> 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1816 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1816/

4 tests failed.
FAILED:  org.apache.solr.cloud.ReindexCollectionTest.testReshapeReindexing

Error Message:
num docs expected:<200> but was:<132>

Stack Trace:
java.lang.AssertionError: num docs expected:<200> but was:<132>
at 
__randomizedtesting.SeedInfo.seed([C832C4E66AEFB94A:236FB7DFC5F475BF]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.cloud.ReindexCollectionTest.indexDocs(ReindexCollectionTest.java:376)
at 
org.apache.solr.cloud.ReindexCollectionTest.testReshapeReindexing(ReindexCollectionTest.java:221)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.hdfs.HdfsUnloadDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=2566, 

Re: Welcome Tomoko Uchida as Lucene/Solr committer

[Gus Heck]

Welcome Tomoko! :)

On Tue, Apr 9, 2019 at 1:57 PM Ahmet Arslan 
wrote:

> Congralations Tomoko!
>
>
>
>
> On Tuesday, April 9, 2019, 8:48:03 PM GMT+3, Robert Muir 
> wrote:
>
>
>
>
>
> Welcome!
>
> On Mon, Apr 8, 2019 at 11:21 AM Uwe Schindler  wrote:
> >
> > Hi all,
> >
> > Please join me in welcoming Tomoko Uchida as the latest Lucene/Solr
> committer!
> >
> > She has been working on
> https://issues.apache.org/jira/browse/LUCENE-2562 for several years with
> awesome progress and finally we got the fantastic Luke as a branch on ASF
> JIRA:
> https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/lucene-2562-luke-swing-3
> > Looking forward to the first release of Apache Lucene 8.1 with Luke
> bundled in the distribution. I will take care of merging it to master and
> 8.x branches together with her once she got the ASF account.
> >
> > Tomoko also helped with the Japanese and Korean Analyzers.
> >
> > Congratulations and Welcome, Tomoko! Tomoko, it's traditional for you to
> introduce yourself with a brief bio.
> >
> > Uwe & Robert (who nominated Tomoko)
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
http://www.the111shift.com

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-12) - Build # 23893 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23893/
Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestCloudSearcherWarming

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestCloudSearcherWarming: 1) Thread[id=22115, 
name=ZkTestServer Run Thread, state=WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@12/java.lang.Object.wait(Native Method) at 
java.base@12/java.lang.Thread.join(Thread.java:1308) at 
java.base@12/java.lang.Thread.join(Thread.java:1375) at 
app//org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:320)
 at 
app//org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:343)
 at 
app//org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:566)2) 
Thread[id=22116, name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, state=RUNNABLE, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@12/sun.nio.ch.EPoll.wait(Native Method) at 
java.base@12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)  
   at 
java.base@12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) 
at java.base@12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136)   
  at 
app//org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:203)
 at java.base@12/java.lang.Thread.run(Thread.java:835)3) 
Thread[id=22119, name=ProcessThread(sid:0 cport:32917):, state=WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@12/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@12/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@12/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@12/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.server.PrepRequestProcessor.run(PrepRequestProcessor.java:123)
4) Thread[id=22117, name=SessionTracker, state=TIMED_WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@12/java.lang.Object.wait(Native Method) at 
app//org.apache.zookeeper.server.SessionTrackerImpl.run(SessionTrackerImpl.java:147)
5) Thread[id=22118, name=SyncThread:0, state=WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@12/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@12/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@12/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@12/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:127)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestCloudSearcherWarming: 
   1) Thread[id=22115, name=ZkTestServer Run Thread, state=WAITING, 
group=TGRP-TestCloudSearcherWarming]
at java.base@12/java.lang.Object.wait(Native Method)
at java.base@12/java.lang.Thread.join(Thread.java:1308)
at java.base@12/java.lang.Thread.join(Thread.java:1375)
at 
app//org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:320)
at 
app//org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:343)
at app//org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:566)
   2) Thread[id=22116, name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, 
state=RUNNABLE, group=TGRP-TestCloudSearcherWarming]
at java.base@12/sun.nio.ch.EPoll.wait(Native Method)
at 
java.base@12/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
at 
java.base@12/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
at java.base@12/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136)
at 
app//org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:203)
at java.base@12/java.lang.Thread.run(Thread.java:835)
   3) Thread[id=22119, name=ProcessThread(sid:0 cport:32917):, state=WAITING, 
group=TGRP-TestCloudSearcherWarming]
at java.base@12/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@12/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@12/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
at 
java.base@12/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
at 
app//org.apache.zookeeper.server.PrepRequestProcessor.run(PrepRequestProcessor.java:123)
   4) Thread[id=22117, 

[JENKINS] Lucene-Solr-Tests-master - Build # 3258 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3258/

All tests passed

Build Log:
[...truncated 52551 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj211469902
 [ecj-lint] Compiling 527 source files to /tmp/ecj211469902
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
 (at line 44)
 [ecj-lint] new TestTokenStream1();
 [ecj-lint] ^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
 (at line 45)
 [ecj-lint] new TestTokenStream2();
 [ecj-lint] ^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestAssertions.java
 (at line 47)
 [ecj-lint] new TestTokenStream3();
 [ecj-lint] ^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
 (at line 130)
 [ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
 [ecj-lint] ^^
 [ecj-lint] Resource leak: 'writer' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
 (at line 120)
 [ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
 [ecj-lint]  
 [ecj-lint] Resource leak: 'analyzer' is never closed
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
 (at line 122)
 [ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'buffer' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
 (at line 29)
 [ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'cs' is never closed
 [ecj-lint] --
 [ecj-lint] 8. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
 (at line 34)
 [ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'cs' is never closed
 [ecj-lint] --
 [ecj-lint] 9. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
 (at line 39)
 [ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new 
StringReader("")));
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'cs' is never closed
 [ecj-lint] --
 [ecj-lint] 10. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
 (at line 44)
 [ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new 
StringReader("")));
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'cs' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 11. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
 (at line 39)
 [ecj-lint] DelegatingAnalyzerWrapper w2 = new 
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
 [ecj-lint]   ^^
 [ecj-lint] Resource leak: 'w2' is never closed
 [ecj-lint] --
 [ecj-lint] 12. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
 (at line 50)
 [ecj-lint] DelegatingAnalyzerWrapper w1 = new 
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
 [ecj-lint]   ^^
 [ecj-lint] Resource leak: 'w1' is never closed
 [ecj-lint] --
 [ecj-lint] 13. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
 (at line 71)
 [ecj-lint] DelegatingAnalyzerWrapper w1 = new 
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
 [ecj-lint]   ^^
 [ecj-lint] Resource leak: 'w1' is never closed
 

[jira] [Created] (LUCENE-8760) Reconsider the best way to encode postings now that we can skip non-competitive hits

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-8760:


 Summary: Reconsider the best way to encode postings now that we 
can skip non-competitive hits
 Key: LUCENE-8760
 URL: https://issues.apache.org/jira/browse/LUCENE-8760
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand


The fact that we now skip non competitive hits has some implications to our 
postings:
 - we are now more likely to call advance vs. nextDoc
 - we are less likely to read term frequency for a given doc, since we only do 
that if the maximum score reported by impacts is competitive
 - we are less likely to read positions for a given doc, since exact phrase 
queries first check the maximum score that would be obtained with a phrase freq 
equal to the minimum of all term freqs

It might be a good opportunity to re-explore the best way to encode postings.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Protect old branches that are not getting new releases?

[Gus Heck]

Slightly behind on mails, but I'd like to Echo Erik ... +1 for protection
-1 for removal.

On Fri, Apr 5, 2019 at 11:22 AM Erick Erickson 
wrote:

> Protecting those branches would answer the question “If we were to change
> the 6.6 branch in order to release a 6.6.7, should I put the changes in 6x
> too” question with “no” ;).
>
> Also, if anyone really wanted to re-open 6x they’d have a known state.
> Well, not 6x since I’m certain some things have been committed there that
> haven’t been committed to 6_6… Er… See what I mean? But going forward….
>
> In some weird case where we wanted to release a 6.7 (which I don’t see
> happening frankly), we could open up the 6x branch again and bump the
> branch on a case-by-case basis. After “frank and open" discussions about
> how that’s not our policy
>
> In general I’m in favor of being unable to screw something up so
> protecting all the branches we shouldn’t modify  from writes is a +1.
>
> I’m -1 for removing branches.
>
> Erick
>
> P.S. And I do note that you carefully did _not_ include 6_6 or 7_7 so we
> can still do the point releases.
>
>
> > On Apr 5, 2019, at 7:47 AM, Adrien Grand  wrote:
> >
> > Removing branches proved a bit controversial in the past, seehttps://
> markmail.org/message/6ah3m6zd6v3ik3ie for instance.
> >
> > On Fri, Apr 5, 2019 at 3:24 PM Shawn Heisey  wrote:
> >>
> >> On 4/5/2019 3:19 AM, Adrien Grand wrote:
> >>> Apparently it is possible to ask INFRA to mark branches as
> >>> protected[1]. Should we do it for branches that are not expecting new
> >>> releases anymore? I think it would make things less trappy. For
> >>> instance, backporting to branch_7x is almost for sure a mistake since
> >>> we are not going to release lucene/solr 7.8.
> >>>
> >>> [1] https://issues.apache.org/jira/browse/INFRA-18109
> >>>
> >>> What would you think of protecting the following branches:
> >>>   branch_3x
> >>>   branch_4x
> >>>   branch_5_4
> >>>   branch_5_5
> >>>   branch_5x
> >>>   branch_6_0
> >>>   branch_6_1
> >>>   branch_6_2
> >>>   branch_6_3
> >>>   branch_6_4
> >>>   branch_6_5
> >>>   branch_6x
> >>>   branch_7_0
> >>>   branch_7_1
> >>>   branch_7_2
> >>>   branch_7_3
> >>>   branch_7_4
> >>>   branch_7_5
> >>>   branch_7_6
> >>>   branch_7x
> >>
> >> In the SVN days, branches were simply deleted when we were through
> >> cutting releases from them.  Deleted branches all came back when we
> >> converted to git.
> >>
> >> Is protecting them the only way to maintain the history?  If so, then
> >> I'm +1.  Does deleting them like we did on SVN make it impossible to "go
> >> back in time" in the repo?
> >>
> >> Thanks,
> >> Shawn
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> >
> > --
> > Adrien
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
http://www.the111shift.com

[jira] [Created] (LUCENE-8759) BlockMaxConjunctionScorer's simplified way of computing max scores hurts performance

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-8759:


 Summary: BlockMaxConjunctionScorer's simplified way of computing 
max scores hurts performance
 Key: LUCENE-8759
 URL: https://issues.apache.org/jira/browse/LUCENE-8759
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand


BlockMaxConjunctionScorer computes the minimum value that the score should have 
after each scorer in order to be able to interrupt scorer as soon as possible. 
For instance say scorers A, B and C produce maximum scores that are equal to 4, 
2 and 1. If the minimum competitive score is X, then the score after scoring A, 
B and C must be at least X, the score after scoring A and B must be at least 
X-1 and the score after scoring A must be at least X-1-2.

However this is made a bit more complex than that due to floating-point numbers 
and the fact that intermediate score values are doubles which only get casted 
to a float after all values have been summed up. In order to keep things 
simple, BlockMaxConjunctionScore has the following comment and code

{code}
// Also compute the minimum required scores for a hit to be competitive
// A double that is less than 'score' might still be converted to 
'score'
// when casted to a float, so we go to the previous float to avoid this 
issue
minScores[minScores.length - 1] = minScore > 0 ? 
Math.nextDown(minScore) : 0;
{code}

It simplifies the problem by calling Math.nextDown(minScore). However this is 
problematic because it defeats the fact that TopScoreDocCollector calls 
setMinCompetitiveScore on the float value that is immediately greater than the 
k-th greatest hit so far.

nextDown(minScore) is not the value that we need. The value that we need is the 
smallest double that converts to minScore when casted to a float, which would 
be half-way between nextDown(minScore) and minScore. In some cases this would 
help get better performance out of conjunctions, especially if some clauses 
produce constant scores.

MaxScoreSumPropagator#setMinCompetitiveScore has the same issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree

[Dominic Page (JIRA)]

Dominic Page created LUCENE-8758:


 Summary: Class Field levelN is not populated correctly in 
QuadPrefixTree
 Key: LUCENE-8758
 URL: https://issues.apache.org/jira/browse/LUCENE-8758
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial-extras
Affects Versions: 8.0, 7.0, 6.0, 5.0, 4.0
Reporter: Dominic Page
 Fix For: 8.x


QuadPrefixTree in Lucene prepopulates these arrays:

{{levelW = new double[maxLevels];}}
{{levelH = new double[maxLevels];}}
{{*levelS = new int[maxLevels];*}}
{{*levelN = new int[maxLevels];*}}

Like this

{{for (int i = 1; i < levelW.length; i++) {}}
{{ levelW[i] = levelW[i - 1] / 2.0;}}
{{ levelH[i] = levelH[i - 1] / 2.0;}}
{{ *levelS[i] = levelS[i - 1] * 2;*}}
{{ *levelN[i] = levelN[i - 1] * 4;*}}
{{}}}

The field

{{levelN[]}}

overflows after level 14 = 1073741824 where maxLevels is limited to 

{{MAX_LEVELS_POSSIBLE = 50;}}

The field levelN appears not to be used anywhere. Likewise, the field

{{levelS[] }}

is only used in the 

{{printInfo}}

method. I would propose either to remove both 

{{levelN[],}}{{levelS[]}}

or to change the datatype

{{levelN = new long[maxLevels];}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-8619) Decrease I/O pressure of OfflineSorter

[Adrien Grand (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand resolved LUCENE-8619.
--
Resolution: Not A Problem

This isn't a problem anymore now that Ignacio rewrote the merging of BKD trees 
as a selection problem rathen than a sorting problem.

> Decrease I/O pressure of OfflineSorter
> --
>
> Key: LUCENE-8619
> URL: https://issues.apache.org/jira/browse/LUCENE-8619
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> OfflineSorter is likely I/O bound, yet it doesn't really try to relieve I/O. 
> For instance it always writes the length on 2 bytes, which is waseful when 
> used by BKDWriter since all byte[] arrays have exactly the same length. For 
> LatLonPoint, this is a 25% space overhead that we could remove.
> Doing lightweight compression on the fly might also help.
> As a data point, Ignacio told me that after indexing 60M shapes with 
> LatLonShape (1.65B triangles), the index directory was about 265GB and 
> dropped to 57GB when merging was over.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org