date:20190725

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/239/
Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseG1GC

8 tests failed.
FAILED:  org.apache.solr.cloud.rule.RulesTest.doIntegrationTest

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:39807/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:39807/solr
at 
__randomizedtesting.SeedInfo.seed([62988027E0B4C067:87ABC7A6FCC03265]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
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:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547)
at 
org.apache.solr.cloud.rule.RulesTest.removeCollections(RulesTest.java:65)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
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 
org.apache.lu

[JENKINS] Lucene-Solr-BadApples-NightlyTests-8.x - Build # 27 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-8.x/27/

No tests ran.

Build Log:
[...truncated 25 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1910 - Still Failing

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

No tests ran.

Build Log:
[...truncated 25 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

Re: [RESULT] [VOTE] Release Lucene/Solr 8.2.0 RC1

2019-07-25 Thread David Smiley

Ignacio,
When you do the final release steps, please try out the updated
addVersion.py here https://issues.apache.org/jira/browse/LUCENE-8883 which
generate more complete and consistent new version sections in CHANGES.txt
for our next release.  I should commit this.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

On Thu, Jul 25, 2019 at 3:58 AM Ignacio Vera  wrote:

> It's been >72h since the vote was initiated and the result is:
>
>
> +1  8  (5 binding)
>
>  0  0
>
> -1  0
>
>
> This vote has PASSED
>
>
> I am +1 to have a separate ANNOUNCE mail in Solr mailing list about the
> bad default as this is not specific to this release.
>
>
>
>

[GitHub] [lucene-solr] atris commented on a change in pull request #803: LUCENE-8929: Early Terminating CollectorManager with Global Hitcount

atris commented on a change in pull request #803: LUCENE-8929: Early 
Terminating CollectorManager with Global Hitcount
URL: https://github.com/apache/lucene-solr/pull/803#discussion_r307583878
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
 ##
 @@ -279,6 +280,125 @@ public void collect(int doc) throws IOException {
 
   }
 
+  /*
+   * Implements a TopFieldCollector that terminates early based on a global
+   * scoreboard which is shared amongst multiple collectors.
+   * NOTE: This should ideally be outside of TopFieldCollector since it does
+   * not have private access, but we keep it here to limit the visibility
+   * of dependent classes
+   */
+  public static class GlobalStateFieldCollector extends TopFieldCollector {
+
+final Sort sort;
+final FieldValueHitQueue queue;
+final AtomicInteger globalTotalHits;
+
+final GlobalStateCollectorManager.GlobalStateCallback callback;
+
+public GlobalStateFieldCollector(Sort sort, FieldValueHitQueue 
queue, int numHits, int totalHitsThreshold,
+ AtomicInteger globalTotalHits, 
GlobalStateCollectorManager.GlobalStateCallback callback) {
+  super(queue, numHits, totalHitsThreshold, sort.needsScores());
+  this.sort = sort;
+  this.queue = queue;
+  this.globalTotalHits = globalTotalHits;
+  this.callback = callback;
+}
+
+@Override
+public LeafCollector getLeafCollector(LeafReaderContext context) throws 
IOException {
+  docBase = context.docBase;
+
+  final LeafFieldComparator[] comparators = queue.getComparators(context);
+  final int[] reverseMul = queue.getReverseMul();
+  final Sort indexSort = context.reader().getMetaData().getSort();
+  final boolean canEarlyTerminate = canEarlyTerminate(sort, indexSort);
+
+  return new MultiComparatorLeafCollector(comparators, reverseMul) {
+
+boolean collectedAllCompetitiveHits = false;
+
+@Override
+public void setScorer(Scorable scorer) throws IOException {
+  super.setScorer(scorer);
+  updateMinCompetitiveScore(scorer);
+}
+
+@Override
+public void collect(int doc) throws IOException {
+  // Increment local hit counter
+  totalHits++;
+
+  if (queueFull) {
+if (collectedAllCompetitiveHits || !isHitCompetitive(doc, scorer)) 
{
+  // since docs are visited in doc Id order, if compare is 0, it 
means
+  // this document is largest than anything else in the queue, and
+  // therefore not competitive.
+  if (canEarlyTerminate) {
+// Check the global scoreboard to see total hits accumulated 
yet
+if (globalTotalHits.incrementAndGet() > totalHitsThreshold) {
+  totalHitsRelation = Relation.GREATER_THAN_OR_EQUAL_TO;
+  throw new CollectionTerminatedException();
+} else {
+  collectedAllCompetitiveHits = true;
+}
+  } else if (totalHitsRelation == Relation.EQUAL_TO) {
+// we just reached totalHitsThreshold, we can start setting 
the min
+// competitive score now
+//TODO: Should we also update competitive score globally?
+updateMinCompetitiveScore(scorer);
+  }
+  return;
+}
+
+// This hit is competitive - replace bottom element in queue & 
adjustTop
+comparator.copy(bottom.slot, doc);
+updateBottom(doc);
+comparator.setBottom(bottom.slot);
+updateMinCompetitiveScore(scorer);
+//Increment global hit counter
+globalTotalHits.incrementAndGet();
+  } else {
+// Startup transient: queue hasn't gathered numHits yet
+
+//Increment global hit counter
+globalTotalHits.incrementAndGet();
+
+final int slot = totalHits - 1;
+
+// Copy hit into queue
+comparator.copy(slot, doc);
+add(slot, doc);
+if (queueFull) {
+  comparator.setBottom(bottom.slot);
+  updateMinCompetitiveScore(scorer);
+}
+  }
+}
+
+// Check if hit is competitive and set the global value accordingly
+private boolean isHitCompetitive(int doc, Scorable scorer) throws 
IOException {
+  // Check if hit is locally competitive
+  if (reverseMul * comparator.compareBottom(doc) > 0) {
+// Hit was competitive locally, but was it globally competitive?
+if (callback.getGlobalMinCompetitiveScore() > scorer.score()) {
+  return false;
+} else {
+  // Hit was locally and globally competitive, set the right
+  // global minimum competitive score
+  callback.checkAndUpdateMinCompetitiveScore(scorer.sco

[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk1.8.0) - Build # 256 - Still unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/256/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

5 tests failed.
FAILED:  
org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest.testCompareSmallPolygons 
{seed=[5D6C4280676077C1:B5093CB2E5078DF5]}

Error Message:
 Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
{planetmodel=PlanetModel.SPHERE, points=[[lat=7.2018759609955395E-6, 
lon=-2.5927628748512177E-4([X=0.999663619701, Y=-2.5927628457345797E-4, 
Z=7.2018759609332826E-6])], [lat=-1.5777218860668716E-4, 
lon=-2.0587374073066655E-4([X=0.999663619702, Y=-2.058737367140635E-4, 
Z=-1.577721879521413E-4])], [lat=-5.140389289736281E-5, 
lon=2.542315875739831E-4([X=0.999663619701, Y=2.542315844994427E-4, 
Z=-5.1403892874724876E-5])], [lat=5.25120189246937E-68, lon=0.0([X=1.0, Y=0.0, 
Z=5.25120189246937E-68])]], internalEdges={3}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.SPHERE, points=[[lat=5.236283340725554E-5, 
lon=-2.0512663678395882E-4([X=0.999775905986, Y=-2.051266350642272E-4, 
Z=5.2362833383326905E-5])], [lat=7.2018759609955395E-6, 
lon=-2.5927628748512177E-4([X=0.999663619701, Y=-2.5927628457345797E-4, 
Z=7.2018759609332826E-6])], [lat=5.25120189246937E-68, lon=0.0([X=1.0, Y=0.0, 
Z=5.25120189246937E-68])], [lat=6.60874884970672E-6, 
lon=1.2720879951544362E-4([X=0.1887123, Y=1.2720879916958188E-4, 
Z=6.6087488496586134E-6])]], internalEdges={1, 3}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.SPHERE, points=[[lat=5.236283340725554E-5, 
lon=-2.0512663678395882E-4([X=0.999775905986, Y=-2.051266350642272E-4, 
Z=5.2362833383326905E-5])], [lat=6.60874884970672E-6, 
lon=1.2720879951544362E-4([X=0.1887123, Y=1.2720879916958188E-4, 
Z=6.6087488496586134E-6])], [lat=1.8775619655369188E-4, 
lon=-1.7895158926606314E-4([X=0.999663619701, Y=-1.7895158515671312E-4, 
Z=1.8775619545054946E-4])]], internalEdges={0}}]}  Large polygon: 
GeoComplexPolygon: {planetmodel=PlanetModel.SPHERE, number of shapes=1, 
address=b51e7f2e, testPoint=[lat=6.393367681777545E-6, 
lon=-6.68268383106406E-5([X=0.77466493, Y=-6.682683825953531E-5, 
Z=6.39336768173399E-6])], testPointInSet=true, shapes={ 
{[lat=-1.5777218860668716E-4, lon=-2.0587374073066655E-4([X=0.999663619702, 
Y=-2.058737367140635E-4, Z=-1.577721879521413E-4])], 
[lat=-5.140389289736281E-5, lon=2.542315875739831E-4([X=0.999663619701, 
Y=2.542315844994427E-4, Z=-5.1403892874724876E-5])], [lat=5.25120189246937E-68, 
lon=0.0([X=1.0, Y=0.0, Z=5.25120189246937E-68])], [lat=6.60874884970672E-6, 
lon=1.2720879951544362E-4([X=0.1887123, Y=1.2720879916958188E-4, 
Z=6.6087488496586134E-6])], [lat=1.8775619655369188E-4, 
lon=-1.7895158926606314E-4([X=0.999663619701, Y=-1.7895158515671312E-4, 
Z=1.8775619545054946E-4])], [lat=5.236283340725554E-5, 
lon=-2.0512663678395882E-4([X=0.999775905986, Y=-2.051266350642272E-4, 
Z=5.2362833383326905E-5])], [lat=7.2018759609955395E-6, 
lon=-2.5927628748512177E-4([X=0.999663619701, Y=-2.5927628457345797E-4, 
Z=7.2018759609332826E-6])]}}  Point: [lat=-1.4229334405147366E-4, 
lon=-2.5E-323([X=0.999898763021, Y=-2.5E-323, Z=-1.422933435712954E-4])]  
WKT: POLYGON((0.014566396986899816 -0.0029452261135613977,0.0 
3.0087170580960566E-66,0.007288527329160751 
3.7865341695013263E-4,-0.010253170802104023 
0.010757637639955277,-0.011752890553433827 
0.0030001693575823743,-0.014855437000718083 
4.126370971417683E-4,-0.011795696456437747 
-0.009039680531705186,0.014566396986899816 -0.0029452261135613977))  WKT: 
POINT(-1.413E-321 -0.0081528080669524) normal polygon: false large polygon: 
true 

Stack Trace:
java.lang.AssertionError: 
Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
{planetmodel=PlanetModel.SPHERE, points=[[lat=7.2018759609955395E-6, 
lon=-2.5927628748512177E-4([X=0.999663619701, Y=-2.5927628457345797E-4, 
Z=7.2018759609332826E-6])], [lat=-1.5777218860668716E-4, 
lon=-2.0587374073066655E-4([X=0.999663619702, Y=-2.058737367140635E-4, 
Z=-1.577721879521413E-4])], [lat=-5.140389289736281E-5, 
lon=2.542315875739831E-4([X=0.999663619701, Y=2.542315844994427E-4, 
Z=-5.1403892874724876E-5])], [lat=5.25120189246937E-68, lon=0.0([X=1.0, Y=0.0, 
Z=5.25120189246937E-68])]], internalEdges={3}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.SPHERE, points=[[lat=5.236283340725554E-5, 
lon=-2.0512663678395882E-4([X=0.999775905986, Y=-2.051266350642272E-4, 
Z=5.2362833383326905E-5])], [lat=7.2018759609955395E-6, 
lon=-2.5927628748512177E-4([X=0.999663619701, Y=-2.5927628457345797E-4, 
Z=7.2018759609332826E-6])], [lat=5.25120189246937E-68, lon=0.0([X=1.0, Y=0.0, 
Z=5.25120189246937E-68])], [lat=6.60874884970672E-6, 
lon=1.2720879951544362E-4([X=0.1887123, Y=1.2720879916958188E-4, 
Z=6.6087488496586134E-6])]], internalEdges={1, 3}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.SPHERE, points=[[lat=5.236283340725554E-5, 
lon=-2.0512663678395882E-4([X=0.999775905986, Y=-2.051266350642272E-4,

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets



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

Tomoko Uchida commented on LUCENE-8933:
---

Just for clarification, let me wrap up the problem here.
 - JapaneseTokenizer has "search mode", which break up dictionary tokens 
(surface forms) to small segments and matches the input text to the segments 
(for increasing search recall).
 - The user dictionary of JapaneseTokenizer allows users to specify arbitrary 
segmentation rules in addition to add custom tokens.
 - e.g.: If an user entry {{"aabbcc,aa bb cc,aa bb cc,pos_tag"}} is given, the 
token stream for {{"aabbcc"}} should generate three tokens, {{"aa"}} {{"bb"}} 
{{"cc"}}.
 - The sum of length of segments are expected to be exactly same to the length 
of corresponding surface form (as [~jim.ferenczi] explained). If a segment is 
longer than its surface form, it's a violation against this assumption and 
causes an AIOOB when array copying the region of surface form.

For purpose of format validation, I think it would be better that we check if 
the sum of length of segments is equal to the length of its surface form.
 i.e., we also should not allow such entry {{"aabbcc,a b c,aa bb cc,pos_tag"}} 
even if this does not cause any exceptions.

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-8.2-Linux (64bit/jdk-12.0.1) - Build # 472 - Still Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.2-Linux/472/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

6 tests failed.
FAILED:  org.apache.solr.cloud.rule.RulesTest.testInvokeApi

Error Message:
Error from server at https://127.0.0.1:33721/solr: Could not find collection : 
rulesColl

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:33721/solr: Could not find collection : 
rulesColl
at 
__randomizedtesting.SeedInfo.seed([58B1B1A30ED156DB:EBA4DC995A332891]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
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:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547)
at 
org.apache.solr.cloud.rule.RulesTest.removeCollections(RulesTest.java:65)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
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)

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 161 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/161/

No tests ran.

Build Log:
[...truncated 25 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-12.0.1) - Build # 5272 - Still unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5272/
Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC

9 tests failed.
FAILED:  org.apache.solr.cloud.rule.RulesTest.doIntegrationTest

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:60378/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:60378/solr
at 
__randomizedtesting.SeedInfo.seed([4D4E27D4EBBD64E0:A87D6055F7C996E2]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
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:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547)
at 
org.apache.solr.cloud.rule.RulesTest.removeCollections(RulesTest.java:65)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
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 
org.apache.lucene

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24449 - Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24449/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom

Error Message:
Error from server at 
http://127.0.0.1:37751/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection:
 Error from server at null: Expected mime type application/octet-stream but got 
text/html.Error 500 Server Error 
 HTTP ERROR 500 Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection_shard2_replica_n2/select.
 Reason: Server ErrorCaused 
by:java.lang.AssertionError  at 
java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896)  at 
java.base/java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2061)  at 
java.base/java.util.HashMap.putVal(HashMap.java:633)  at 
java.base/java.util.HashMap.put(HashMap.java:607)  at 
org.apache.solr.search.LRUCache.put(LRUCache.java:201)  at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
  at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)  at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484)
  at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:398)
  at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2581)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)
  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 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at org.eclipse.jetty.server.Server.handle(Server.java:505)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)  at 
org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:311)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
  at java.base/java.lang.Thread.run(Thread.java:834)  http://eclipse.org/jetty";>Powered by Jetty:// 9.4.19.v20190610  
  

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


Error 500 Server Error

HTTP ERROR 500
Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection_shard2_replica_n2/select.
 Reason:
Server ErrorCaused by:java.lang.AssertionError
at 
java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896)
at java.base/java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2061)
at java.base/java.util.HashMap.putVal(HashMap.java:633)
at java.base/java.util.HashMap.put(HashMap.java:607)
at org.apache.solr.search.LRUCache.put(LRUCache.java:201)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)
at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484)
at 
org.apache.solr

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 425 - Failure

2019-07-25 Thread ASF subversion and git services (JIRA)

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testCreateLargeSimCollections

Error Message:
last ClusterState: znodeVersion: 1141 live nodes:[127.0.0.1:10351_solr, 
127.0.0.1:10365_solr, 127.0.0.1:10382_solr, 127.0.0.1:10334_solr, 
127.0.0.1:10349_solr, 127.0.0.1:10379_solr, 127.0.0.1:10404_solr, 
127.0.0.1:10320_solr, 127.0.0.1:10418_solr, 127.0.0.1:10381_solr, 
127.0.0.1:10366_solr, 127.0.0.1:10321_solr, 127.0.0.1:10396_solr, 
127.0.0.1:10335_solr, 127.0.0.1:10419_solr, 127.0.0.1:10378_solr, 
127.0.0.1:10383_solr, 127.0.0.1:10394_solr, 127.0.0.1:10397_solr, 
127.0.0.1:10353_solr, 127.0.0.1:10350_solr, 127.0.0.1:10417_solr, 
127.0.0.1:10337_solr, 127.0.0.1:10406_solr, 127.0.0.1:10367_solr, 
127.0.0.1:10348_solr, 127.0.0.1:10403_solr, 127.0.0.1:10364_solr, 
127.0.0.1:10380_solr, 127.0.0.1:10354_solr, 127.0.0.1:10376_solr, 
127.0.0.1:10407_solr, 127.0.0.1:10331_solr, 127.0.0.1:10338_solr, 
127.0.0.1:10363_solr, 127.0.0.1:10370_solr, 127.0.0.1:10385_solr, 
127.0.0.1:10401_solr, 127.0.0.1:10369_solr, 127.0.0.1:10416_solr, 
127.0.0.1:10332_solr, 127.0.0.1:10347_solr, 127.0.0.1:10341_solr, 
127.0.0.1:10413_solr, 127.0.0.1:10325_solr, 127.0.0.1:10410_solr, 
127.0.0.1:10328_solr, 127.0.0.1:10344_solr, 127.0.0.1:10392_solr, 
127.0.0.1:10360_solr, 127.0.0.1:10398_solr, 127.0.0.1:10395_solr, 
127.0.0.1:10322_solr, 127.0.0.1:10390_solr, 127.0.0.1:10326_solr, 
127.0.0.1:10357_solr, 127.0.0.1:10412_solr, 127.0.0.1:10373_solr, 
127.0.0.1:10374_solr, 127.0.0.1:10343_solr, 127.0.0.1:10388_solr, 
127.0.0.1:10327_solr, 127.0.0.1:10389_solr, 127.0.0.1:10375_solr, 
127.0.0.1:10386_solr, 127.0.0.1:10414_solr, 127.0.0.1:10342_solr, 
127.0.0.1:10359_solr, 127.0.0.1:10345_solr, 127.0.0.1:10400_solr, 
127.0.0.1:10409_solr, 127.0.0.1:10391_solr, 127.0.0.1:10361_solr, 
127.0.0.1:10356_solr, 127.0.0.1:10411_solr, 127.0.0.1:10372_solr, 
127.0.0.1:10329_solr, 127.0.0.1:10393_solr, 127.0.0.1:10362_solr, 
127.0.0.1:10399_solr, 127.0.0.1:10371_solr, 127.0.0.1:10384_solr, 
127.0.0.1:10323_solr, 127.0.0.1:10368_solr, 127.0.0.1:10415_solr, 
127.0.0.1:10377_solr, 127.0.0.1:10324_solr, 127.0.0.1:10346_solr, 
127.0.0.1:10340_solr, 127.0.0.1:10330_solr, 127.0.0.1:10405_solr, 
127.0.0.1:10402_solr, 127.0.0.1:10408_solr, 127.0.0.1:10358_solr, 
127.0.0.1:10333_solr, 127.0.0.1:10355_solr, 127.0.0.1:10352_solr, 
127.0.0.1:10339_solr, 127.0.0.1:10336_solr, 127.0.0.1:10387_solr] 
collections:{large_sim_collection4=DocCollection(large_sim_collection4//clusterstate.json/1140)={
   "replicationFactor":"1",   "pullReplicas":"16",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"9",   
"autoAddReplicas":"false",   "nrtReplicas":"14",   "tlogReplicas":"10",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node54":{   "core":"large_sim_collection4_shard2_replica_n54",
   "SEARCHER.searcher.maxDoc":0,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":10240, 
  "node_name":"127.0.0.1:10332_solr",   "state":"active",   
"type":"NRT",   "INDEX.sizeInGB":9.5367431640625E-6,   
"SEARCHER.searcher.numDocs":0}, "core_node76":{   
"core":"large_sim_collection4_shard2_replica_p76",   
"SEARCHER.searcher.maxDoc":0,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":10240,   "node_name":"127.0.0.1:10413_solr",   
"state":"active",   "type":"PULL",   
"INDEX.sizeInGB":9.5367431640625E-6,   "SEARCHER.searcher.numDocs":0},  
   "core_node53":{   
"core":"large_sim_collection4_shard2_replica_n53",   
"SEARCHER.searcher.maxDoc":0,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":10240,   "node_name":"127.0.0.1:10411_solr",   
"state":"active",   "type":"NRT",   
"INDEX.sizeInGB":9.5367431640625E-6,   "SEARCHER.searcher.numDocs":0},  
   "core_node75":{   
"core":"large_sim_collection4_shard2_replica_p75",   
"SEARCHER.searcher.maxDoc":0,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":10240,   "node_name":"127.0.0.1:10352_solr",   
"state":"active",   "type":"PULL",   
"INDEX.sizeInGB":9.5367431640625E-6,   "SEARCHER.searcher.numDocs":0},  
   "core_node78":{   
"core":"large_sim_collection4_shard2_replica_p78",   
"SEARCHER.searcher.maxDoc":0,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":10240,   "node_name":"127.0.0.1:10364_solr",   
"state":"active",   "type":"PULL",   
"INDEX.sizeInGB":9.5367431640625E-6,   "SEARCHER.searcher.numDocs":0},  
   "core_node56":{   
"core":"large_sim_collection4_shard2_replica_t56",   
"SEARCHER.searcher.maxDoc":0,   "SEARCHER

[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete

2019-07-25 Thread Nicholas Knize (JIRA)



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

Nicholas Knize commented on LUCENE-8369:


{quote}Can we simply make the necessary APIs public and marked 
{{@lucene.internal}} in our core spatial classes?
{quote}

I think that's what we were trying to avoid because it largely feels like a cop 
out to making a foundation class package private vice keeping it exposed. One 
example is {{EdgeTree}} this can (and probably should) stay package private to 
{{org.apache.lucene.geo}}. But it's used for {{XYShape}}, {{LatLonShape}}, and 
{{LatLonPoint}}. So if we fragment those classes between the {{core}} and 
{{spatial}} module we are forcing ourselves to keep it public and mark it 
{{@lucene.internal}}. Which, again, feels like a cop out to doing (in my 
opinion) the "right" thing and making it package private.   

> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially why the module existed.  Better late than never.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13637) Enable loading of plugins from the corecontainer memclassloader

2019-07-25 Thread Ishan Chattopadhyaya (JIRA)



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

Ishan Chattopadhyaya commented on SOLR-13637:
-

For some reason, using carrot's version of ImmutableMap was causing the Eclipse 
project to not work (import not found). Switched to Google's version in the 
above commit, and it now works fine.

> Enable loading of plugins from the corecontainer memclassloader
> ---
>
> Key: SOLR-13637
> URL: https://issues.apache.org/jira/browse/SOLR-13637
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
> Attachments: BasicAuthFails.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When we update jars or add/modify plugins no core reloading should be 
> required .Core reloading is a very expensive operation. Optionally, we can 
> just make the plugin depend on the corecontainer level classloader. 
> {code:xml}
>   runtimeLib="global">
>  
>   
> {code}
> or alternately using the config API 
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "create-queryparser": {
>   "name": "mycustomQParser" ,
>   "class" : "my.path.to.ClassName",
>  "runtimeLib" : "global"
>   }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
> The global classloader is the corecontainer level classloader . So whenever 
> this is reloaded The component gets reloaded. The only caveat is, this 
> component cannot use core specific jars.
> We will deprecate the {{runtimeLib = true/false}} option and the new options 
> are 
> * {{runtimeLib=core}} : means this uses the runtimeLib of the collection
> * {{runtimeLib= global}} : means this uses the runtimeLib of the 
> corecontainer 
> example command to update global jar . This will lead to a reload of all 
> components marked as {{runtimeLib=global}}
> {code}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "update-runtimelib": {
>   "name": "lib-name" ,
>   "url" : "http://host:port/url/of/jar";,
>   "sha512":""
>   }
> }' http://localhost:8983/api/cluster
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13637) Enable loading of plugins from the corecontainer memclassloader



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

ASF subversion and git services commented on SOLR-13637:


Commit fdcf3155c72771708ce643b51d75277cac162ae8 in lucene-solr's branch 
refs/heads/branch_8x from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fdcf315 ]

SOLR-13637: Using google common's ImmutableMap instead of carrot's


> Enable loading of plugins from the corecontainer memclassloader
> ---
>
> Key: SOLR-13637
> URL: https://issues.apache.org/jira/browse/SOLR-13637
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
> Attachments: BasicAuthFails.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When we update jars or add/modify plugins no core reloading should be 
> required .Core reloading is a very expensive operation. Optionally, we can 
> just make the plugin depend on the corecontainer level classloader. 
> {code:xml}
>   runtimeLib="global">
>  
>   
> {code}
> or alternately using the config API 
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "create-queryparser": {
>   "name": "mycustomQParser" ,
>   "class" : "my.path.to.ClassName",
>  "runtimeLib" : "global"
>   }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
> The global classloader is the corecontainer level classloader . So whenever 
> this is reloaded The component gets reloaded. The only caveat is, this 
> component cannot use core specific jars.
> We will deprecate the {{runtimeLib = true/false}} option and the new options 
> are 
> * {{runtimeLib=core}} : means this uses the runtimeLib of the collection
> * {{runtimeLib= global}} : means this uses the runtimeLib of the 
> corecontainer 
> example command to update global jar . This will lead to a reload of all 
> components marked as {{runtimeLib=global}}
> {code}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "update-runtimelib": {
>   "name": "lib-name" ,
>   "url" : "http://host:port/url/of/jar";,
>   "sha512":""
>   }
> }' http://localhost:8983/api/cluster
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13637) Enable loading of plugins from the corecontainer memclassloader

2019-07-25 Thread ASF subversion and git services (JIRA)



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

ASF subversion and git services commented on SOLR-13637:


Commit c20988907f28954967de3395ea5421ee56ec4b35 in lucene-solr's branch 
refs/heads/master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c209889 ]

SOLR-13637: Using google common's ImmutableMap instead of carrot's


> Enable loading of plugins from the corecontainer memclassloader
> ---
>
> Key: SOLR-13637
> URL: https://issues.apache.org/jira/browse/SOLR-13637
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
> Attachments: BasicAuthFails.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When we update jars or add/modify plugins no core reloading should be 
> required .Core reloading is a very expensive operation. Optionally, we can 
> just make the plugin depend on the corecontainer level classloader. 
> {code:xml}
>   runtimeLib="global">
>  
>   
> {code}
> or alternately using the config API 
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "create-queryparser": {
>   "name": "mycustomQParser" ,
>   "class" : "my.path.to.ClassName",
>  "runtimeLib" : "global"
>   }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
> The global classloader is the corecontainer level classloader . So whenever 
> this is reloaded The component gets reloaded. The only caveat is, this 
> component cannot use core specific jars.
> We will deprecate the {{runtimeLib = true/false}} option and the new options 
> are 
> * {{runtimeLib=core}} : means this uses the runtimeLib of the collection
> * {{runtimeLib= global}} : means this uses the runtimeLib of the 
> corecontainer 
> example command to update global jar . This will lead to a reload of all 
> components marked as {{runtimeLib=global}}
> {code}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "update-runtimelib": {
>   "name": "lib-name" ,
>   "url" : "http://host:port/url/of/jar";,
>   "sha512":""
>   }
> }' http://localhost:8983/api/cluster
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk1.8.0_201) - Build # 381 - Still Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/381/
Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testFileStreamDirectoryCrawl

Error Message:
expected: but was:

Stack Trace:
org.junit.ComparisonFailure: expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([79AAEAD38DA0EBD7:DD43243F41AF8C32]:0)
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testFileStreamDirectoryCrawl(StreamExpressionTest.java:3128)
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.io.stream.StreamExpressionTest.testFileStreamDirectoryCrawl

Error Message:
expected: but was:

Stack Trace:
org.junit.ComparisonFailure: expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([7

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

2019-07-25 Thread ASF subversion and git services (JIRA)

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

All tests passed

Build Log:
[...truncated 55228 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1354506292
 [ecj-lint] Compiling 127 source files to /tmp/ecj1354506292
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/DemoHTMLParser.java
 (at line 23)
 [ecj-lint] import java.util.Arrays;
 [ecj-lint]
 [ecj-lint] The import java.util.Arrays is never used
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/DemoHTMLParser.java
 (at line 24)
 [ecj-lint] import java.util.Collections;
 [ecj-lint]^
 [ecj-lint] The import java.util.Collections is never used
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/DemoHTMLParser.java
 (at line 26)
 [ecj-lint] import java.util.HashSet;
 [ecj-lint]^
 [ecj-lint] The import java.util.HashSet is never used
 [ecj-lint] --
 [ecj-lint] 3 problems (3 errors)

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:634: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:101: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build.xml:207:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2181:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2009:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2048:
 Compile failed; see the compiler error output for details.

Total time: 96 minutes 36 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
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] (LUCENE-8927) Cut Over To Set.copyOf and Set.Of From Collections.unmodifiableSet



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

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

Commit 90dd3f768fc97b569710188e3a38e9769e281f26 in lucene-solr's branch 
refs/heads/master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=90dd3f7 ]

LUCENE-8927: Fixing precommit / removing unused import


> Cut Over To Set.copyOf and Set.Of From Collections.unmodifiableSet
> --
>
> Key: LUCENE-8927
> URL: https://issues.apache.org/jira/browse/LUCENE-8927
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8927) Cut Over To Set.copyOf and Set.Of From Collections.unmodifiableSet

2019-07-25 Thread Ishan Chattopadhyaya (JIRA)



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

Ishan Chattopadhyaya commented on LUCENE-8927:
--

Precommit fails for me, possibly due to this commit.
{code}
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj649495649
 [ecj-lint] Compiling 127 source files to /tmp/ecj649495649
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/home/ishan/code/lucene-solr/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/DemoHTMLParser.java
 (at line 23)
 [ecj-lint] import java.util.Arrays;
 [ecj-lint]
 [ecj-lint] The import java.util.Arrays is never used
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/ishan/code/lucene-solr/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/DemoHTMLParser.java
 (at line 24)
 [ecj-lint] import java.util.Collections;
 [ecj-lint]^
 [ecj-lint] The import java.util.Collections is never used
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/ishan/code/lucene-solr/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/feeds/DemoHTMLParser.java
 (at line 26)
 [ecj-lint] import java.util.HashSet;
 [ecj-lint]^
 [ecj-lint] The import java.util.HashSet is never used
 [ecj-lint] --
 [ecj-lint] 3 problems (3 errors)

BUILD FAILED
/home/ishan/code/lucene-solr/build.xml:101: The following error occurred while 
executing this line:
/home/ishan/code/lucene-solr/lucene/build.xml:207: The following error occurred 
while executing this line:
/home/ishan/code/lucene-solr/lucene/common-build.xml:2181: The following error 
occurred while executing this line:
/home/ishan/code/lucene-solr/lucene/common-build.xml:2009: The following error 
occurred while executing this line:
/home/ishan/code/lucene-solr/lucene/common-build.xml:2048: Compile failed; see 
the compiler error output for details.
{code}

> Cut Over To Set.copyOf and Set.Of From Collections.unmodifiableSet
> --
>
> Key: LUCENE-8927
> URL: https://issues.apache.org/jira/browse/LUCENE-8927
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete

2019-07-25 Thread Michael McCandless (JIRA)



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

Michael McCandless commented on LUCENE-8369:


{quote}Lots of awesome functionality _commonly_ needed in search is in our 
modules – like highlighting, autocomplete, and spellcheck, to name a few. Why 
should spatial be an exception?
{quote}
Well, other examples are default analysis ({{StandardAnalyzer}}), common 
queries (versus exotic queries in the queries module), most {{Directory}} 
implementations, where we have some common choices in core and more exotic 
choices in our modules.

I think it (the "common" classes and the "exotic" ones) is a helpful 
distinction for our users for areas that have many many options.

[~nknize] can you give a concrete example where the code sharing is making 
things difficult?  Can we simply make the necessary APIs public and marked 
{{@lucene.internal}} in our core spatial classes?

> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially why the module existed.  Better late than never.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
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_201) - Build # 921 - Still Unstable!

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest.testMetricTrigger

Error Message:
Timeout occurred while waiting response from server at: 
http://127.0.0.1:38461/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: http://127.0.0.1:38461/solr
at 
__randomizedtesting.SeedInfo.seed([CE77048925FE799C:747B33067A16AFD3]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
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:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest.testMetricTrigger(MetricTriggerIntegrationTest.java:88)
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.randomi

[jira] [Created] (SOLR-13654) Scary jenkins failure related to collection creation: "non legacy mode coreNodeName missing"

Hoss Man created SOLR-13654:
---

 Summary: Scary jenkins failure related to collection creation: 
"non legacy mode coreNodeName missing"
 Key: SOLR-13654
 URL: https://issues.apache.org/jira/browse/SOLR-13654
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
 Attachments: thetaphi_Lucene-Solr-8.2-Linux_452.log.txt

A recent SplitShardTest jenkins failure has a perplexing error that i've been 
updable to reproduce...

{noformat}
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36447/_bx/t: Underlying core creation failed 
while creating collection: shardSplitWithRule_link
{noformat}

...this exception is thrown when attempting to create a brand new 1x2 
collection (prior to any splitting) using the following rule/request...

{noformat}
CollectionAdminRequest.Create createRequest = 
CollectionAdminRequest.createCollection(collectionName, "conf1", 1, 2)
.setRule("shard:*,replica:<2,node:*");
{noformat}

...the logs indicate that the specific problem is that the CREATE SolrCore 
commands aren't inlcuding a 'coreNodeName' which is mandatory because this is a 
"non legacy" clusuter...

{noformat}
   [junit4]   2> 1090551 ERROR (OverseerThreadFactory-6577-thread-5) [ ] 
o.a.s.c.a.c.OverseerCollectionMessageHandler Error from shard: 
http://127.0.0.1:36447/_bx/t
   [junit4]   2>   => 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36447/_bx/t: Error CREATEing SolrCore 
'shardSplitWithRule_link_shard1_replica_n1': non legacy mode coreNodeName 
missing {collection.configName=conf1, numShards=1, shard=shard1, 
collection=shardSplitWithRule_link, replicaType=NRT}
   [junit4]   2>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
   [junit4]   2> 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36447/_bx/t: Error CREATEing SolrCore 
'shardSplitWithRule_link_shard1_replica_n1': non legacy mode coreNodeName 
missing {collection.configName=conf1, numShards=1, shard=shard1, 
collection=shardSplitWithRule_link, replicaType=NRT}
   [junit4]   2>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
 ~[java/:?]
   [junit4]   2>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
 ~[java/:?]
   [junit4]   2>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
 ~[java/:?]
   [junit4]   2>at 
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1274) ~[java/:?]
   [junit4]   2>at 
org.apache.solr.handler.component.HttpShardHandlerFactory$1.request(HttpShardHandlerFactory.java:176)
 ~[java/:?]
   [junit4]   2>at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:199)
 ~[java/:?]
   [junit4]   2>at 
java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
{noformat}

...so how/why is the Overseer generating CREATE core commands w/o coreNodeName 
params 

Is this a race condition between the test setting legacyCloud=false and the 
Overseer processing the CREATE collection Op?




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8620) Add CONTAINS support for LatLonShape

2019-07-25 Thread Trent Nadeau (JIRA)



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

Trent Nadeau commented on LUCENE-8620:
--

Any updates on this?

> Add CONTAINS support for LatLonShape
> 
>
> Key: LUCENE-8620
> URL: https://issues.apache.org/jira/browse/LUCENE-8620
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8620.patch, LUCENE-8620.patch
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> Currently the only spatial operation that cannot be performed using 
> {{LatLonShape}} is CONTAINS. This issue will add such capability by tracking 
> if an edge of a generated triangle from the {{Tessellator}} is an edge of the 
> polygon.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
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 #166: POMs out of sync

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

No tests ran.

Build Log:
[...truncated 33254 lines...]
  [mvn] [INFO] -
  [mvn] [INFO] -
  [mvn] [ERROR] COMPILATION ERROR : 
  [mvn] [INFO] -

[...truncated 803 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:680: The 
following error occurred while executing this line:
: Java returned: 1

Total time: 24 minutes 3 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-8.2-Linux (64bit/jdk-12.0.1) - Build # 471 - Still Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.2-Linux/471/
Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC

10 tests failed.
FAILED:  
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:32821/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:32821/solr
at 
__randomizedtesting.SeedInfo.seed([569DFA33B77A9A5D:3C8B9BE3DF88D097]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
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:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:256)
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:567)
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.evalua

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24448 - Failure!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24448/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 2037 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J0-20190725_173129_70613040801239811925659.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 

   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J1-20190725_173129_7062959523695258740414.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 5 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J2-20190725_173129_7064245919457208185725.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 301 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/test-framework/test/temp/junit4-J0-20190725_174331_5786467321373010318676.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-20190725_174331_5785774214108474725260.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-20190725_174331_5786373824435530451019.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 1082 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20190725_174531_7048793880241943068014.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 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20190725_174531_7031858087728040045020.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 J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20190725_174531_70313100522436319884709.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 241 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/analysis/icu/test/temp/junit4-J1-20190725_174804_79810843559921369433729.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/analysis/icu/test/temp/junit4-J2-20190725_174804_798146919047470

[jira] [Resolved] (LUCENE-8927) Cut Over To Set.copyOf and Set.Of From Collections.unmodifiableSet



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

Adrien Grand resolved LUCENE-8927.
--
   Resolution: Fixed
Fix Version/s: master (9.0)

> Cut Over To Set.copyOf and Set.Of From Collections.unmodifiableSet
> --
>
> Key: LUCENE-8927
> URL: https://issues.apache.org/jira/browse/LUCENE-8927
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.3) - Build # 8068 - Still Unstable!

2019-07-25 Thread ASF subversion and git services (JIRA)

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8068/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

7 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
IOException occurred when talking to server at: https://127.0.0.1:63292/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occurred when 
talking to server at: https://127.0.0.1:63292/solr
at 
__randomizedtesting.SeedInfo.seed([EF3A0C7F7BABD447:BF6F947C228A625A]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:670)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
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:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.teardown(MissingSegmentRecoveryTest.java:87)
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$10.evaluate(RandomizedRunner.java:996)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.ap

[jira] [Commented] (LUCENE-8927) Cut Over To Set.copyOf and Set.Of From Collections.unmodifiableSet



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

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

Commit 3e2ca05b8eacbd81791daf950c4d56bfa971574d in lucene-solr's branch 
refs/heads/master from Atri Sharma
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3e2ca05 ]

LUCENE-8927: Set.copyOf and Set.of instead of Collections.unmodifiabl… (#796)



> Cut Over To Set.copyOf and Set.Of From Collections.unmodifiableSet
> --
>
> Key: LUCENE-8927
> URL: https://issues.apache.org/jira/browse/LUCENE-8927
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] jpountz merged pull request #796: LUCENE-8927: Set.copyOf and Set.of instead of Collections.unmodifiabl…

jpountz merged pull request #796: LUCENE-8927: Set.copyOf and Set.of instead of 
Collections.unmodifiabl…
URL: https://github.com/apache/lucene-solr/pull/796
 
 
   


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] [Resolved] (LUCENE-8931) TestTopFieldCollectorEarlyTermination Should Use CheckHits



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

Adrien Grand resolved LUCENE-8931.
--
   Resolution: Fixed
Fix Version/s: 8.3

> TestTopFieldCollectorEarlyTermination Should Use CheckHits
> --
>
> Key: LUCENE-8931
> URL: https://issues.apache.org/jira/browse/LUCENE-8931
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
> Fix For: 8.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> TestTopFieldCollectorEarlyTermination invents a new way of checking equality 
> of hits. That is redundant since CheckHits provides the same functionality 
> and is the de facto standard now.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (LUCENE-8922) Speed up retrieval of top hits of DisjunctionMaxQuery

2019-07-25 Thread ASF subversion and git services (JIRA)



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

Adrien Grand resolved LUCENE-8922.
--
   Resolution: Fixed
Fix Version/s: 8.3

> Speed up retrieval of top hits of DisjunctionMaxQuery
> -
>
> Key: LUCENE-8922
> URL: https://issues.apache.org/jira/browse/LUCENE-8922
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There a simple optimization that we are not doing in the case that 
> tieBreakMultiplier is 0: we could propagate the min competitive score to sub 
> clauses as-is.
> Even in the general case, we currently compute the block boundary of the 
> DisjunctionMaxQuery as the minimum of the block boundaries of its sub 
> clauses. This generates blocks that have very low score upper bounds but 
> unfortunately they are also very small, which means that we might sometimes 
> not make progress quickly enough.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8931) TestTopFieldCollectorEarlyTermination Should Use CheckHits



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

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

Commit e4ed92c4c5ccac31e0de83d9395b83f7dda3a775 in lucene-solr's branch 
refs/heads/branch_8x from Atri Sharma
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e4ed92c ]

LUCENE-8931: Remove Custom ScoreDoc Equality Method (#806)



> TestTopFieldCollectorEarlyTermination Should Use CheckHits
> --
>
> Key: LUCENE-8931
> URL: https://issues.apache.org/jira/browse/LUCENE-8931
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> TestTopFieldCollectorEarlyTermination invents a new way of checking equality 
> of hits. That is redundant since CheckHits provides the same functionality 
> and is the de facto standard now.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] jpountz commented on a change in pull request #803: LUCENE-8929: Early Terminating CollectorManager with Global Hitcount

jpountz commented on a change in pull request #803: LUCENE-8929: Early 
Terminating CollectorManager with Global Hitcount
URL: https://github.com/apache/lucene-solr/pull/803#discussion_r307432751
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/TopFieldCollector.java
 ##
 @@ -279,6 +280,125 @@ public void collect(int doc) throws IOException {
 
   }
 
+  /*
+   * Implements a TopFieldCollector that terminates early based on a global
+   * scoreboard which is shared amongst multiple collectors.
+   * NOTE: This should ideally be outside of TopFieldCollector since it does
+   * not have private access, but we keep it here to limit the visibility
+   * of dependent classes
+   */
+  public static class GlobalStateFieldCollector extends TopFieldCollector {
+
+final Sort sort;
+final FieldValueHitQueue queue;
+final AtomicInteger globalTotalHits;
+
+final GlobalStateCollectorManager.GlobalStateCallback callback;
+
+public GlobalStateFieldCollector(Sort sort, FieldValueHitQueue 
queue, int numHits, int totalHitsThreshold,
+ AtomicInteger globalTotalHits, 
GlobalStateCollectorManager.GlobalStateCallback callback) {
+  super(queue, numHits, totalHitsThreshold, sort.needsScores());
+  this.sort = sort;
+  this.queue = queue;
+  this.globalTotalHits = globalTotalHits;
+  this.callback = callback;
+}
+
+@Override
+public LeafCollector getLeafCollector(LeafReaderContext context) throws 
IOException {
+  docBase = context.docBase;
+
+  final LeafFieldComparator[] comparators = queue.getComparators(context);
+  final int[] reverseMul = queue.getReverseMul();
+  final Sort indexSort = context.reader().getMetaData().getSort();
+  final boolean canEarlyTerminate = canEarlyTerminate(sort, indexSort);
+
+  return new MultiComparatorLeafCollector(comparators, reverseMul) {
+
+boolean collectedAllCompetitiveHits = false;
+
+@Override
+public void setScorer(Scorable scorer) throws IOException {
+  super.setScorer(scorer);
+  updateMinCompetitiveScore(scorer);
+}
+
+@Override
+public void collect(int doc) throws IOException {
+  // Increment local hit counter
+  totalHits++;
+
+  if (queueFull) {
+if (collectedAllCompetitiveHits || !isHitCompetitive(doc, scorer)) 
{
+  // since docs are visited in doc Id order, if compare is 0, it 
means
+  // this document is largest than anything else in the queue, and
+  // therefore not competitive.
+  if (canEarlyTerminate) {
+// Check the global scoreboard to see total hits accumulated 
yet
+if (globalTotalHits.incrementAndGet() > totalHitsThreshold) {
+  totalHitsRelation = Relation.GREATER_THAN_OR_EQUAL_TO;
+  throw new CollectionTerminatedException();
+} else {
+  collectedAllCompetitiveHits = true;
+}
+  } else if (totalHitsRelation == Relation.EQUAL_TO) {
+// we just reached totalHitsThreshold, we can start setting 
the min
+// competitive score now
+//TODO: Should we also update competitive score globally?
+updateMinCompetitiveScore(scorer);
+  }
+  return;
+}
+
+// This hit is competitive - replace bottom element in queue & 
adjustTop
+comparator.copy(bottom.slot, doc);
+updateBottom(doc);
+comparator.setBottom(bottom.slot);
+updateMinCompetitiveScore(scorer);
+//Increment global hit counter
+globalTotalHits.incrementAndGet();
+  } else {
+// Startup transient: queue hasn't gathered numHits yet
+
+//Increment global hit counter
+globalTotalHits.incrementAndGet();
+
+final int slot = totalHits - 1;
+
+// Copy hit into queue
+comparator.copy(slot, doc);
+add(slot, doc);
+if (queueFull) {
+  comparator.setBottom(bottom.slot);
+  updateMinCompetitiveScore(scorer);
+}
+  }
+}
+
+// Check if hit is competitive and set the global value accordingly
+private boolean isHitCompetitive(int doc, Scorable scorer) throws 
IOException {
+  // Check if hit is locally competitive
+  if (reverseMul * comparator.compareBottom(doc) > 0) {
+// Hit was competitive locally, but was it globally competitive?
+if (callback.getGlobalMinCompetitiveScore() > scorer.score()) {
+  return false;
+} else {
+  // Hit was locally and globally competitive, set the right
+  // global minimum competitive score
+  callback.checkAndUpdateMinCompetitiveScore(scorer.s

[JENKINS] Lucene-Solr-repro - Build # 3476 - Still Unstable

2019-07-25 Thread ASF subversion and git services (JIRA)

Build: https://builds.apache.org/job/Lucene-Solr-repro/3476/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/160/consoleText

[repro] Revision: d842b45727bf65443c10f82968791c124aa5f5a5

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestRandomChains 
-Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=B7F9ED9937C42EAD 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=de-CH -Dtests.timezone=Etc/GMT+12 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
29f941baa2e46738446b99aed1d1b3288b49f45c
[repro] git fetch
[repro] git checkout d842b45727bf65443c10f82968791c124aa5f5a5

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]lucene/analysis/common
[repro]   TestRandomChains
[repro] ant compile-test

[...truncated 237 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestRandomChains" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=B7F9ED9937C42EAD -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=de-CH -Dtests.timezone=Etc/GMT+12 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 366 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   5/5 failed: org.apache.lucene.analysis.core.TestRandomChains

[repro] Re-testing 100% failures at the tip of branch_8x
[repro] git fetch
[repro] git checkout branch_8x

[...truncated 4 lines...]
[repro] git merge --ff-only

[...truncated 16 lines...]
[repro] ant clean

[...truncated 7 lines...]
[repro] Test suites by module:
[repro]lucene/analysis/common
[repro]   TestRandomChains
[repro] ant compile-test

[...truncated 237 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestRandomChains" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=B7F9ED9937C42EAD -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=de-CH -Dtests.timezone=Etc/GMT+12 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 365 lines...]
[repro] Setting last failure code to 256

[repro] Failures at the tip of branch_8x:
[repro]   5/5 failed: org.apache.lucene.analysis.core.TestRandomChains

[repro] Re-testing 100% failures at the tip of branch_8x without a seed
[repro] ant clean

[...truncated 7 lines...]
[repro] Test suites by module:
[repro]lucene/analysis/common
[repro]   TestRandomChains
[repro] ant compile-test

[...truncated 237 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestRandomChains" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=de-CH -Dtests.timezone=Etc/GMT+12 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 344 lines...]
[repro] Setting last failure code to 256

[repro] Failures at the tip of branch_8x without a seed:
[repro]   5/5 failed: org.apache.lucene.analysis.core.TestRandomChains
[repro] git checkout 29f941baa2e46738446b99aed1d1b3288b49f45c

[...truncated 8 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

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

[jira] [Commented] (LUCENE-8931) TestTopFieldCollectorEarlyTermination Should Use CheckHits



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

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

Commit 29f941baa2e46738446b99aed1d1b3288b49f45c in lucene-solr's branch 
refs/heads/master from Atri Sharma
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=29f941b ]

LUCENE-8931: Remove Custom ScoreDoc Equality Method (#806)



> TestTopFieldCollectorEarlyTermination Should Use CheckHits
> --
>
> Key: LUCENE-8931
> URL: https://issues.apache.org/jira/browse/LUCENE-8931
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> TestTopFieldCollectorEarlyTermination invents a new way of checking equality 
> of hits. That is redundant since CheckHits provides the same functionality 
> and is the de facto standard now.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] jpountz merged pull request #806: LUCENE-8931: Remove Custom ScoreDoc Equality Method

jpountz merged pull request #806: LUCENE-8931: Remove Custom ScoreDoc Equality 
Method
URL: https://github.com/apache/lucene-solr/pull/806
 
 
   


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 #2624: POMs out of sync

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

No tests ran.

Build Log:
[...truncated 34698 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:680: 
The following error occurred while executing this line:
: Java returned: 1

Total time: 27 minutes 9 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

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 3453 - Failure

2019-07-25 Thread Chris Hostetter


This failure is caused by a JDK HashMap AssertionError, which 
reproduces fairly easily for me using java11, but not with java12.

I *think* it's the same bug as JDK-8205399 -- first identified in java10, 
and fixed in java12...

https://bugs.openjdk.java.net/browse/JDK-8205399

I filed a SOLR issue to try and capture for posterity how this bug can 
affect Solr users, but it's not clear to me how big the impact is (does 
this cause data corruption in the HashMap, or just loss of performance in 
the balance of the RB Tree?) ... and either way there doesn't seem to be 
much we can do about it?

https://issues.apache.org/jira/browse/SOLR-13653

What really confuses me, is that the "fix" for JDK-8205399 was identified 
and committed to the OpenJDK repo 2018-08-10, but doesn't seem to have 
been backported for inclusion in either 11.0.2 or 11.0.3.

(/cc rory in case he can provide any insights)




: Date: Thu, 25 Jul 2019 04:42:40 + (UTC)
: From: Apache Jenkins Server 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-Tests-master - Build # 3453 - Failure
: 
: Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3453/
: 
: 1 tests failed.
: FAILED:  org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom
: 
: Error Message:
: Error from server at 
http://127.0.0.1:42227/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection:
 Expected mime type application/octet-stream but got text/html.   
 
Error 500 Server Error  HTTP ERROR 500 
Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection/select. 
Reason: Server ErrorCaused 
by:java.lang.AssertionError  at 
java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896)  at 
java.base/java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2061)  at 
java.base/java.util.HashMap.putVal(HashMap.java:633)  at 
java.base/java.util.HashMap.put(HashMap.java:607)  at 
org.apache.solr.search.LRUCache.put(LRUCache.java:201)  at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
  at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:
 568)  at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484)
  at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:398)
  at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2581)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)
  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 org.eclipse.jetty.servlet.ServletHandler$Cac
 hedChain.doFilter(ServletHandler.java:1610)  at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at org.eclipse.jetty.serv
 er.handler.gzip.GzipHandler.handle(GzipHandler.java:753)  at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at org.eclipse.jetty.server.Server.handle(Server.java:505)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)  at 
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
  at java.base/ja

[jira] [Commented] (LUCENE-4312) Index format to store position length per position

2019-07-25 Thread Michael Gibney (JIRA)



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

Michael Gibney commented on LUCENE-4312:


For the sake of facilitating discussion around something more concrete, I 
uploaded a patch ([^positionLength-postings.patch]) for a straw-man proposal 
for {{PostingsEnum}} modifications to support position length (also visible as 
a pseudo-PR here: [https://github.com/magibney/lucene-solr/pull/1]). The patch 
won't compile, of course (no corresponding modifications to subclasses of 
{{PostingsEnum}}).

The proposal goes a bit beyond simply adding a {{positionLength()}} method, 
with a few additional fundamental methods to support optimizations that proved 
helpful in implementing performant positional queries (for LUCENE-7398).

Any feedback would be much appreciated, especially given the acknowledged 
provisional (and potentially controversial) nature of this proposal.

[~jpountz], I've given some more thought to the challenge of not being able to 
"advance positions on terms in the order we want anymore". I think there should 
be a general-purpose way to preserve this ability (in a way that doesn't depend 
on the kind of corpus-specific shingle-based filtering that I previously 
suggested). I'm considering an approach leveraging something analogous to a 
reverse token filter, except rather than reversing the token text, it (sort of) 
reverses start/end positions: start position of the new token is end position 
of the original token, and end position of the new token is 
{{originalEndPosition + positionLength}}. Then you could use the least-cost 
term as an entrypoint, and build forward with original tokens, backward with 
the modified-positions tokens. Query implementation would be responsible for 
properly interpreting flipped positions.

 

> Index format to store position length per position
> --
>
> Key: LUCENE-4312
> URL: https://issues.apache.org/jira/browse/LUCENE-4312
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Affects Versions: 6.0
>Reporter: Gang Luo
>Priority: Minor
>  Labels: Suggestion
> Attachments: positionLength-postings.patch
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Mike Mccandless said:TokenStreams are actually graphs.
> Indexer ignores PositionLengthAttribute.Need change the index format (and 
> Codec APIs) to store an additional int position length per position.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-13653) java (10 & 11) HashMap bug can trigger AssertionError when using SolrCaches



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

Hoss Man resolved SOLR-13653.
-
Resolution: Information Provided
  Assignee: Hoss Man

> java (10 & 11) HashMap bug can trigger AssertionError when using SolrCaches
> ---
>
> Key: SOLR-13653
> URL: https://issues.apache.org/jira/browse/SOLR-13653
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
>  Labels: Java10, java11
>
> we've seen some java11 jenkins builds that have failed due to an 
> AssertionError being thrown by HashMap.put as used in LRUCache -- in at least 
> one case these failures are semi-reproducible. (the occasional "success" is 
> likely due to some unpredictibility in thread contention)
> Some cursory investigation suggests that JDK-8205399, first identified in 
> java10, and fixed in java12-b26...
> https://bugs.openjdk.java.net/browse/JDK-8205399
> There does not appear to be anything we can do to mitigate this problem in 
> Solr.  
> It's also not clear to me based on th comments in JDK-8205399 if the 
> underlying problem can cause problems for end users running w/assertions 
> disabled, or if it just results in sub-optimal performance



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13653) java (10 & 11) HashMap bug can trigger AssertionError when using SolrCaches



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

Hoss Man commented on SOLR-13653:
-

sample failure from jenkins...

http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-Tests-master/3453
{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestCloudJSONFacetSKG -Dtests.method=testRandom 
-Dtests.seed=B1CFC66C4378F63 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=rn -Dtests.timezone=Africa/Kampala -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   18.5s J1 | TestCloudJSONFacetSKG.testRandom <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at 
http://127.0.0.1:42227/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection:
 Expected mime type application/octet-stream but got text/html. 
   [junit4]> 
   [junit4]> 
   [junit4]> Error 500 Server Error
   [junit4]> 
   [junit4]> HTTP ERROR 500
   [junit4]> Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection/select. 
Reason:
   [junit4]> Server ErrorCaused 
by:java.lang.AssertionError
   [junit4]>at 
java.base/java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1896)
   [junit4]>at 
java.base/java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2061)
   [junit4]>at java.base/java.util.HashMap.putVal(HashMap.java:633)
   [junit4]>at java.base/java.util.HashMap.put(HashMap.java:607)
   [junit4]>at 
org.apache.solr.search.LRUCache.put(LRUCache.java:201)
   [junit4]>at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
   [junit4]>at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)
   [junit4]>at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484)
   [junit4]>at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:398)
   [junit4]>at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305)
   [junit4]>at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
   [junit4]>at 
org.apache.solr.core.SolrCore.execute(SolrCore.java:2581)
{noformat}

As of dc8e9afff92f3ffc4081a2ecad5970eb09924a73 this seeds reproduces fairly 
reliably for me using...

{noformat}
hossman@tray:~/lucene/dev/solr/core [j11] [master] $ java -version
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment 18.9 (build 11.0.3+7)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode)
hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test -Dtests.dups=10 
-Dtests.failfast=no -Dtestcase=TestCloudJSONFacetSKG -Dtests.method=testRandom 
-Dtests.seed=B1CFC66C4378F63 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=rn -Dtests.timezone=Africa/Kampala -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
...
   [junit4] Tests with failures [seed: B1CFC66C4378F63]:
   [junit4]   - org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom
   [junit4]   - org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom
   [junit4]   - org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom
   [junit4]   - org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom
   [junit4]   - org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom
   [junit4]   - org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom
   [junit4]   - org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom
   [junit4]   - org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom
   [junit4] 
   [junit4] 
   [junit4] JVM J0: 1.38 ..   126.31 =   124.93s
   [junit4] JVM J1: 1.39 ..   128.17 =   126.77s
   [junit4] JVM J2: 1.35 ..   123.50 =   122.15s
   [junit4] Execution time total: 2 minutes 8 seconds
   [junit4] Tests summary: 10 suites, 10 tests, 8 errors

BUILD FAILED
{noformat}


> java (10 & 11) HashMap bug can trigger AssertionError when using SolrCaches
> ---
>
> Key: SOLR-13653
> URL: https://issues.apache.org/jira/browse/SOLR-13653
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
>  Labels: Java10, java11
>
> we've seen some java11 jenkins builds that have failed due to an 
> AssertionError being thrown by HashMap.put as used in LRUCache -- in at least 
> one case these failures are semi-reproducible. (the occasional "success" is 
> likely due to some unpredictibility in thread contention)
> Some curso

[jira] [Created] (SOLR-13653) java (10 & 11) HashMap bug can trigger AssertionError when using SolrCaches

Hoss Man created SOLR-13653:
---

 Summary: java (10 & 11) HashMap bug can trigger AssertionError 
when using SolrCaches
 Key: SOLR-13653
 URL: https://issues.apache.org/jira/browse/SOLR-13653
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


we've seen some java11 jenkins builds that have failed due to an AssertionError 
being thrown by HashMap.put as used in LRUCache -- in at least one case these 
failures are semi-reproducible. (the occasional "success" is likely due to some 
unpredictibility in thread contention)

Some cursory investigation suggests that JDK-8205399, first identified in 
java10, and fixed in java12-b26...

https://bugs.openjdk.java.net/browse/JDK-8205399

There does not appear to be anything we can do to mitigate this problem in 
Solr.  
It's also not clear to me based on th comments in JDK-8205399 if the underlying 
problem can cause problems for end users running w/assertions disabled, or if 
it just results in sub-optimal performance



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
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 (32bit/jdk1.8.0_201) - Build # 920 - Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/920/
Java: 32bit/jdk1.8.0_201 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.search.facet.TestCloudJSONFacetSKG.testRandom

Error Message:
Error from server at 
http://127.0.0.1:39189/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection:
 Expected mime type application/octet-stream but got text/html.   
 
Error 500 Server Error  HTTP ERROR 500 
Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection/select. 
Reason: Server ErrorCaused 
by:java.lang.AssertionError  at 
java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1849)  at 
java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2014)  at 
java.util.HashMap.putVal(HashMap.java:638)  at 
java.util.HashMap.put(HashMap.java:612)  at 
org.apache.solr.search.LRUCache.put(LRUCache.java:201)  at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
  at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)  at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1484)
  at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:398)
  at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2592)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)
  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 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:753)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at org.eclipse.jetty.server.Server.handle(Server.java:505)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)  at 
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
  at java.lang.Thread.run(Thread.java:748)  http://eclipse.org/jetty";>Powered by Jetty:// 9.4.19.v20190610  
  

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


Error 500 Server Error

HTTP ERROR 500
Problem accessing 
/solr/org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection/select. 
Reason:
Server ErrorCaused by:java.lang.AssertionError
at java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1849)
at java.util.HashMap$TreeNode.putTreeVal(HashMap.java:2014)
at java.util.HashMap.putVal(HashMap.java:638)
at java.util.HashMap.put(HashMap.java:612)
at org.apache.solr.search.LRUCache.put(LRUCache.java:201)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1449)
at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)
at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroup

[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 159 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/159/

No tests ran.

Build Log:
[...truncated 24989 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2590 links (2119 relative) to 3405 anchors in 259 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.3.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:c

[jira] [Updated] (LUCENE-4312) Index format to store position length per position

2019-07-25 Thread Michael Gibney (JIRA)



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

Michael Gibney updated LUCENE-4312:
---
Attachment: positionLength-postings.patch

> Index format to store position length per position
> --
>
> Key: LUCENE-4312
> URL: https://issues.apache.org/jira/browse/LUCENE-4312
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Affects Versions: 6.0
>Reporter: Gang Luo
>Priority: Minor
>  Labels: Suggestion
> Attachments: positionLength-postings.patch
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Mike Mccandless said:TokenStreams are actually graphs.
> Indexer ignores PositionLengthAttribute.Need change the index format (and 
> Codec APIs) to store an additional int position length per position.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets



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

Tomoko Uchida commented on LUCENE-8933:
---

[~danmuzi]: thanks for confirmation, sorry it relates only to 
JapaneseTokenizer's search mode and its user dictionary format. KoreanTokenizer 
and its user dictionary should not have same problem.

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13579) Create resource management API



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

Andrzej Bialecki  updated SOLR-13579:
-
Attachment: (was: SOLR-13579.patch)

> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, 
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
>
> Resource management framework API supporting the goals outlined in SOLR-13578.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13579) Create resource management API



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

Andrzej Bialecki  updated SOLR-13579:
-
Attachment: SOLR-13579.patch

> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, 
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
>
> Resource management framework API supporting the goals outlined in SOLR-13578.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-NightlyTests-8.2 - Build # 13 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.2/13/

No tests ran.

Build Log:
[...truncated 25 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
a

[jira] [Commented] (SOLR-13399) compositeId support for shard splitting



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

Hoss Man commented on SOLR-13399:
-

bq. (unless you mean we've generally moved to doing doc it as part of the 
initial commit? If so, I missed that.)

yes, that's the entire value add of keeping the ref-guide in the same repo as 
the source, and having it as part of the main build w/precommit.

we've been trying to move to having the "code release process" and the 
"ref-guide release process" be a single process, with a single vote -- and 
we're getting close -- but the main hold up is people who add features w/o docs 
and then forcing a scramble during the release process to back fill docs on new 
features.

> compositeId support for shard splitting
> ---
>
> Key: SOLR-13399
> URL: https://issues.apache.org/jira/browse/SOLR-13399
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13399.patch, SOLR-13399.patch
>
>
> Shard splitting does not currently have a way to automatically take into 
> account the actual distribution (number of documents) in each hash bucket 
> created by using compositeId hashing.
> We should probably add a parameter *splitByPrefix* to the *SPLITSHARD* 
> command that would look at the number of docs sharing each compositeId prefix 
> and use that to create roughly equal sized buckets by document count rather 
> than just assuming an equal distribution across the entire hash range.
> Like normal shard splitting, we should bias against splitting within hash 
> buckets unless necessary (since that leads to larger query fanout.) . Perhaps 
> this warrants a parameter that would control how much of a size mismatch is 
> tolerable before resorting to splitting within a bucket. 
> *allowedSizeDifference*?
> To more quickly calculate the number of docs in each bucket, we could index 
> the prefix in a different field.  Iterating over the terms for this field 
> would quickly give us the number of docs in each (i.e lucene keeps track of 
> the doc count for each term already.)  Perhaps the implementation could be a 
> flag on the *id* field... something like *indexPrefixes* and poly-fields that 
> would cause the indexing to be automatically done and alleviate having to 
> pass in an additional field during indexing and during the call to 
> *SPLITSHARD*.  This whole part is an optimization though and could be split 
> off into its own issue if desired.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-8.2-Linux (64bit/jdk-12.0.1) - Build # 470 - Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.2-Linux/470/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.rule.RulesTest.doIntegrationTest

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:36919/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:36919/solr
at 
__randomizedtesting.SeedInfo.seed([5F2E11247AD7B57:E0C1A6935BD98955]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
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:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547)
at 
org.apache.solr.cloud.rule.RulesTest.removeCollections(RulesTest.java:65)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
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 
org.apache.lucene.util.Test

[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 249 - Still unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/249/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime

Error Message:
Expected no errors: [{type=ADD,id=1,message=Underlying core creation failed 
while creating collection: testCatTime__CRA__tabby__TRA__2019-07-01}]

Stack Trace:
java.lang.AssertionError: Expected no errors: 
[{type=ADD,id=1,message=Underlying core creation failed while creating 
collection: testCatTime__CRA__tabby__TRA__2019-07-01}]
at 
__randomizedtesting.SeedInfo.seed([7072FA0F5C3B5B50:7779B50C63C80AB8]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.update.processor.RoutedAliasUpdateProcessorTest.assertUpdateResponse(RoutedAliasUpdateProcessorTest.java:329)
at 
org.apache.solr.update.processor.RoutedAliasUpdateProcessorTest.addDocsAndCommit(RoutedAliasUpdateProcessorTest.java:296)
at 
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime(DimensionalRoutedAliasUpdateProcessorTest.java:375)
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(TestRuleIgnoreTestS

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets

2019-07-25 Thread Namgyu Kim (JIRA)



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

Namgyu Kim commented on LUCENE-8933:


Great analysis! :D
 I checked KoreanTokenizer and there is no issue with this code.
{code:java}
@Test
public void test() throws IOException {
  UserDictionary dict = UserDictionary.open(new StringReader("aaa,,,"));
  KoreanTokenizer tok = new 
KoreanTokenizer(KoreanTokenizer.DEFAULT_TOKEN_ATTRIBUTE_FACTORY, dict, 
DecompoundMode.NONE, true);
  tok.setReader(new StringReader("aaa"));
  tok.reset();
  tok.incrementToken();
}
{code}

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13652) Remove update from initParams in example solrconfig files that only mention "df"

2019-07-25 Thread Alexandre Rafalovitch (JIRA)



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

Alexandre Rafalovitch commented on SOLR-13652:
--

There is two reference to update there. One just update and one wildcard. The 
proposal is to remove both? 

I wonder if the wildcard option hits some sort of use-case that we may not 
remember about.

> Remove update from initParams in example solrconfig files that only mention 
> "df"
> 
>
> Key: SOLR-13652
> URL: https://issues.apache.org/jira/browse/SOLR-13652
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Priority: Minor
>  Labels: easyfix, newbie
>
> At least some of the solrconfig files we ship have this entry:
>  path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse,update">
>     
>   text
>     
>   
>  
> which has lead at least one user to wonder if there's some kind of automatic 
> way to have the df field populated for updates. I don't even know how you'd 
> send an update that didn't have a specific field. We should remove the 
> "update/**".



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13579) Create resource management API



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

Andrzej Bialecki  commented on SOLR-13579:
--

Updated patch:
 * renamed ManagedResource to ManagedComponent
 * consistently use the name "component" instead of the confusing "resource"

> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, 
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
>
> Resource management framework API supporting the goals outlined in SOLR-13578.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13579) Create resource management API



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

Andrzej Bialecki  updated SOLR-13579:
-
Attachment: SOLR-13579.patch

> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, 
> SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch
>
>
> Resource management framework API supporting the goals outlined in SOLR-13578.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13650) Support for named global classloaders

2019-07-25 Thread Noble Paul (JIRA)



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

Noble Paul updated SOLR-13650:
--
Description: 
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
  "add-package": {
   "name": "my-package" ,
  "url" : "http://host:port/url/of/jar";,
  "sha512":""
  }
}' http://localhost:8983/api/cluster

{code}

This means that Solr creates a globally accessible classloader with a name 
{{my-package}} which contains all the jars of that package. 
A component should be able to use the package by using the {{"package" : 
"my-package"}}.
eg:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
  "create-searchcomponent": {
  "name": "my-searchcomponent" ,
  "class" : "my.path.to.ClassName",
 "package" : "my-package"
  }
}' http://localhost:8983/api/c/mycollection/config 
{code}

  was:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
  "add-runtimelib": {
   "name": "my-package" ,
  "url" : "http://host:port/url/of/jar";,
  "sha512":""
  }
}' http://localhost:8983/api/cluster

{code}

This means that Solr creates a globally accessible classloader with a name 
{{my-package}} which contains all the jars of that package. 
A component should be able to use the package by using the {{"runtimeLib" : 
"my-package"}}.
eg:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
  "create-searchcomponent": {
  "name": "my-searchcomponent" ,
  "class" : "my.path.to.ClassName",
 "runtimeLib" : "my-package"
  }
}' http://localhost:8983/api/c/mycollection/config 
{code}


> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "add-package": {
>"name": "my-package" ,
>   "url" : "http://host:port/url/of/jar";,
>   "sha512":""
>   }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name 
> {{my-package}} which contains all the jars of that package. 
> A component should be able to use the package by using the {{"package" : 
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "create-searchcomponent": {
>   "name": "my-searchcomponent" ,
>   "class" : "my.path.to.ClassName",
>  "package" : "my-package"
>   }
> }' http://localhost:8983/api/c/mycollection/config 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13650) Support for named global classloaders

2019-07-25 Thread Noble Paul (JIRA)



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

Noble Paul updated SOLR-13650:
--
Description: 
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
  "add-runtimelib": {
   "name": "my-package" ,
  "url" : "http://host:port/url/of/jar";,
  "sha512":""
  }
}' http://localhost:8983/api/cluster

{code}

This means that Solr creates a globally accessible classloader with a name 
{{my-package}} which contains all the jars of that package. 
A component should be able to use the package by using the {{"runtimeLib" : 
"my-package"}}.
eg:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
  "create-searchcomponent": {
  "name": "my-searchcomponent" ,
  "class" : "my.path.to.ClassName",
 "runtimeLib" : "my-package"
  }
}' http://localhost:8983/api/c/mycollection/config 
{code}

  was:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
  "add-runtimelib": {
 "package": "my-package",
  "name": "jar-name" ,
  "url" : "http://host:port/url/of/jar";,
  "sha512":""
  }
}' http://localhost:8983/api/cluster

{code}

This means that Solr creates a globally accessible classloader with a name 
{{my-package}} which contains all the jars of that package. 
A component should be able to use the package by using the {{"runtimeLib" : 
"my-package"}}.
eg:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
  "create-searchcomponent": {
  "name": "my-searchcomponent" ,
  "class" : "my.path.to.ClassName",
 "runtimeLib" : "my-package"
  }
}' http://localhost:8983/api/c/mycollection/config 
{code}


> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "add-runtimelib": {
>"name": "my-package" ,
>   "url" : "http://host:port/url/of/jar";,
>   "sha512":""
>   }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name 
> {{my-package}} which contains all the jars of that package. 
> A component should be able to use the package by using the {{"runtimeLib" : 
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
>   "create-searchcomponent": {
>   "name": "my-searchcomponent" ,
>   "class" : "my.path.to.ClassName",
>  "runtimeLib" : "my-package"
>   }
> }' http://localhost:8983/api/c/mycollection/config 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13625) Add CsvStream, TsvStream Streaming Expressions and supporting Stream Evaluators

2019-07-25 Thread Joel Bernstein (JIRA)



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

Joel Bernstein updated SOLR-13625:
--
Summary: Add CsvStream, TsvStream Streaming Expressions and supporting 
Stream Evaluators  (was: Add CsvStream Streaming Expression)

> Add CsvStream, TsvStream Streaming Expressions and supporting Stream 
> Evaluators
> ---
>
> Key: SOLR-13625
> URL: https://issues.apache.org/jira/browse/SOLR-13625
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13625.patch, SOLR-13625.patch, SOLR-13625.patch, 
> SOLR-13625.patch, SOLR-13625.patch
>
>
> The CsvStream Streaming Expression parses CSV files and  loads fields into 
> tuples for indexing into Solr Cloud collections.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete

2019-07-25 Thread Nicholas Knize (JIRA)



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

Nicholas Knize commented on LUCENE-8369:


{quote}Such core use cases should work easily for users without wading thru 
extra jars, third party dependencies, crazy licensing, or crazy class 
hierarchies.
{quote}
I agree. That's why the `spatial` module should remain dependency free and 
apache licensed.
{quote}I don't think adding esoteric functionality (like non-WGS shapes)
{quote}
Except esoteric is in the eye of the beholder so claiming someone will 
understand or prefer latitude longitude search any more than basic x, y is 
assumptive.
{quote}My fear of having LatLonPoint in a different package to other spatial 
fields is code sharing
{quote}
I agree. When we only had LatLonPoint I leaned toward it moving to the spatial 
module because of how we could advance the foundation. But since we weren't 
there yet, I could understand the argument for having "...basic functionality 
in core that solves the 90% geo use case". Now we've added geo shapes and a 
cartesian coordinate system and it's quickly becoming a fragmentation issue 
impeding development. IMHO it's clearer and cleaner for the dependency free 
spatial code to all exist together in the same module called {{spatial}}. Is 
there any technical downside or argument against removing it from core? Or is 
it all a matter of opinion?

> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially why the module existed.  Better late than never.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete

2019-07-25 Thread Ignacio Vera (JIRA)



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

Ignacio Vera commented on LUCENE-8369:
--

My fear of having LatLonPoint in a different package to other spatial fields is 
code sharing. Most of the code used by LatLotPoint is reused when dealing with 
more complex shapes and having them in different packages hurts the API 
(Objects that should be package protected become public because the need of 
reuse them). This has been already the case working in the sandbox.

> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially why the module existed.  Better late than never.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Created] (SOLR-13652) Remove update from initParams in example solrconfig files that only mention "df"

2019-07-25 Thread Erick Erickson (JIRA)

Erick Erickson created SOLR-13652:
-

 Summary: Remove update from initParams in example solrconfig files 
that only mention "df"
 Key: SOLR-13652
 URL: https://issues.apache.org/jira/browse/SOLR-13652
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson


At least some of the solrconfig files we ship have this entry:


    
  text
    
  

 

which has lead at least one user to wonder if there's some kind of automatic 
way to have the df field populated for updates. I don't even know how you'd 
send an update that didn't have a specific field. We should remove the 
"update/**".



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-12638) Support atomic updates of nested/child documents for nested-enabled schema

2019-07-25 Thread David Smiley (JIRA)



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

David Smiley commented on SOLR-12638:
-

CC [~moshebla]
I found the cause of this bug or maybe non-bug depending on how you want to 
look at it.   For partial updates to nested documents to work, it is _not only_ 
necessary to have the \_nest_path_ field in the schema, but the \_root_ field 
must be stored=true.   If either are false then any such partial updates will 
wipe out child documents.  So the cause here is actually very similar to 
SOLR-13523.  
org.apache.solr.update.processor.NestedAtomicUpdateTest#testBlockAtomicStack 
exercises partial updates and it passes... but it passes because this test 
suite uses the test schema-nest.xml with root stored=true.

When I was working on SOLR-13523 I started to work on wiping out all traces of 
stored=true in all schemas but it got to be a chunk of work that was a bit 
distracting from a simple bug fix so I had tabled it.  But that would have 
surfaced this problem then had I continued.  Perhaps _for now_, root with 
stored=true this is simply a requirement for partial updates to work in the 
presence of nested docs.  We don't document that and it's a problem.  I also 
think this requirement stinks... I'd much rather this feature work without 
having to toggle the stored attribute because I think it's a source of errors 
(e.g. this issue), something to document, something to want to test in 
different ways, and ultimately not truly necessary if we code this better.

> Support atomic updates of nested/child documents for nested-enabled schema
> --
>
> Key: SOLR-12638
> URL: https://issues.apache.org/jira/browse/SOLR-12638
> Project: Solr
>  Issue Type: Sub-task
>Reporter: mosh
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-12638-delete-old-block-no-commit.patch, 
> SOLR-12638-nocommit.patch, SOLR-12638.patch, SOLR-12638.patch
>
>  Time Spent: 17h 10m
>  Remaining Estimate: 0h
>
> I have been toying with the thought of using this transformer in conjunction 
> with NestedUpdateProcessor and AtomicUpdate to allow SOLR to completely 
> re-index the entire nested structure. This is just a thought, I am still 
> thinking about implementation details. Hopefully I will be able to post a 
> more concrete proposal soon.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #797: LUCENE-8921: IndexSearcher.termStatistics requires docFreq totalTermFreq instead of TermStates

bruno-roustant commented on a change in pull request #797: LUCENE-8921: 
IndexSearcher.termStatistics requires docFreq totalTermFreq instead of 
TermStates
URL: https://github.com/apache/lucene-solr/pull/797#discussion_r307301256
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
 ##
 @@ -861,17 +861,17 @@ public String toString() {
   
   /**
* Returns {@link TermStatistics} for a term, or {@code null} if
-   * the term does not exist.
+   * the term does not exist (if docFreq == 0).
* 
* This can be overridden for example, to return a term's statistics
* across a distributed collection.
* @lucene.experimental
*/
-  public TermStatistics termStatistics(Term term, TermStates context) throws 
IOException {
-if (context.docFreq() == 0) {
+  public TermStatistics termStatistics(Term term, int docFreq, long 
totalTermFreq) throws IOException {
+if (docFreq == 0) {
 
 Review comment:
   Previously all callers checked if the returned TermStatistics was null 
before doing something. So I replaced the null check by a check if docFreq is 0.
   I tried to remove the 0 check and ran TestShardSearching (which extends 
ShardSearchingTestBase I modified). It failed with the exception because 
docFreq was 0.
   I think this check is necessary, unless some specific class is sure docFreq 
will always be > 0. If that was the case it would not previously check null.


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

[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #797: LUCENE-8921: IndexSearcher.termStatistics requires docFreq totalTermFreq instead of TermStates

bruno-roustant commented on a change in pull request #797: LUCENE-8921: 
IndexSearcher.termStatistics requires docFreq totalTermFreq instead of 
TermStates
URL: https://github.com/apache/lucene-solr/pull/797#discussion_r307301256
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
 ##
 @@ -861,17 +861,17 @@ public String toString() {
   
   /**
* Returns {@link TermStatistics} for a term, or {@code null} if
-   * the term does not exist.
+   * the term does not exist (if docFreq == 0).
* 
* This can be overridden for example, to return a term's statistics
* across a distributed collection.
* @lucene.experimental
*/
-  public TermStatistics termStatistics(Term term, TermStates context) throws 
IOException {
-if (context.docFreq() == 0) {
+  public TermStatistics termStatistics(Term term, int docFreq, long 
totalTermFreq) throws IOException {
+if (docFreq == 0) {
 
 Review comment:
   Previously all callers checked if the returned TermStatistics was null 
before doing something. So I replaced the null check by a check if docFreq is 0.
   I tried to remove the 0 check and ran TestShardSearching (which extends 
ShardSearchingTestBase I modified). It failed with the exception because 
docFreq was 0.
   I think this check is necessary, unless some specific class is sure docFreq 
will always be > 0. In this case it would not previously check null.


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

[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #797: LUCENE-8921: IndexSearcher.termStatistics requires docFreq totalTermFreq instead of TermStates

bruno-roustant commented on a change in pull request #797: LUCENE-8921: 
IndexSearcher.termStatistics requires docFreq totalTermFreq instead of 
TermStates
URL: https://github.com/apache/lucene-solr/pull/797#discussion_r307301256
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
 ##
 @@ -861,17 +861,17 @@ public String toString() {
   
   /**
* Returns {@link TermStatistics} for a term, or {@code null} if
-   * the term does not exist.
+   * the term does not exist (if docFreq == 0).
* 
* This can be overridden for example, to return a term's statistics
* across a distributed collection.
* @lucene.experimental
*/
-  public TermStatistics termStatistics(Term term, TermStates context) throws 
IOException {
-if (context.docFreq() == 0) {
+  public TermStatistics termStatistics(Term term, int docFreq, long 
totalTermFreq) throws IOException {
+if (docFreq == 0) {
 
 Review comment:
   Previously all callers checked if the returned TermStatistics was null 
before doing something. So I replaced the null check by a check if docFreq is 0.
   I tried to remove the 0 check and ran TestShardSearching (which extends 
ShardSearchingTestBase I modified). It failed with the exception because 
docFreq was 0.
   I think this check is necessary, unless some specific class is sure docFreq 
will always be > 0. It this case it would not previously check null.


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] (SOLR-13539) Atomic Update Multivalue remove does not work for field types UUID, Enums, Bool and Binary

2019-07-25 Thread JIRA



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

Thomas Wöckinger commented on SOLR-13539:
-

Pushed new version with additional DirectJson tests

> Atomic Update Multivalue remove does not work for field types UUID, Enums, 
> Bool  and Binary
> ---
>
> Key: SOLR-13539
> URL: https://issues.apache.org/jira/browse/SOLR-13539
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.7.2, 8.1, 8.1.1
>Reporter: Thomas Wöckinger
>Priority: Critical
>  Time Spent: 6.5h
>  Remaining Estimate: 0h
>
> When using JavaBinCodec the values of collections are of type 
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove 
> Operation does not have any effect.
>  This is related to following field types: UUID, Enums, Bool and Binary



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] thomaswoeckinger commented on issue #665: Fixes SOLR-13539

thomaswoeckinger commented on issue #665: Fixes SOLR-13539
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-515045605
 
 
   > I was able to clean up some of the failures locally by removing the second 
clause in the if-statement below. (This was added in this PR in 
EmbeddedSolrServer)
   > 
   > ```
   >  private Set getContentStreams(final SolrRequest 
request) throws IOException {
   > if (request.getMethod() == SolrRequest.METHOD.GET || request 
instanceof QueryRequest) return null;
   > ```
   > 
   > This makes sensethere are some QueryRequest implementations that are 
supposed to be POST's. (e.g. JSON-queries and JSON-faceting requests, Solr 
tagging requests, etc.). But there are still other failing tests that rely on 
SolrJettyTestBase. So I haven't figured it out yet, but something's still not 
quite right in that base-class.
   > 
   > With Cao Manh Dat working on the 8.1.2 release, and Ignacio Vera talking 
about an 8.2 shortly afterward, if we can't figure out the test issues soon, it 
might be best to split the functionality changes and test-base changes into two 
separate PR's if possible. I'd hate for this fix to miss the next crop of 
releases because we couldn't cross the finish line on test-changes also bundled 
into this commit.
   
   Reverted the if statement, reason was that internal code requires the whole 
content response to be null. Added DirectJsonQueryRequestFacetingEmbeddedTest 
to prove functionality.
   
   A general comment, it would be great to switch to junit 5, test cases could 
be extracted to default interfaces and all test classes simply have to 
implement it and provide their solr client.


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-8369) Remove the spatial module as it is obsolete

2019-07-25 Thread David Smiley (JIRA)



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

David Smiley commented on LUCENE-8369:
--

Lots of awesome functionality _commonly_ needed in search is in our modules -- 
like highlighting, autocomplete, and spellcheck, to name a few.  Why should 
spatial be an exception?

> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially why the module existed.  Better late than never.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #798: LUCENE-8906: Lucene50PostingsFormat.IntBlockTermState becomes public

2019-07-25 Thread ASF subversion and git services (JIRA)

bruno-roustant commented on a change in pull request #798: LUCENE-8906: 
Lucene50PostingsFormat.IntBlockTermState becomes public
URL: https://github.com/apache/lucene-solr/pull/798#discussion_r307295236
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50PostingsFormat.java
 ##
 @@ -453,15 +453,15 @@ public FieldsProducer fieldsProducer(SegmentReadState 
state) throws IOException
 }
   }
   
-  final static class IntBlockTermState extends BlockTermState {
-long docStartFP = 0;
-long posStartFP = 0;
-long payStartFP = 0;
-long skipOffset = -1;
-long lastPosBlockOffset = -1;
+  public static final class IntBlockTermState extends BlockTermState {
 
 Review comment:
   You're right. I had hard time to fix all the javadoc for the precommit. I 
imposes to have a constructor doc since we have fields initialized with non 0 
value. So I added a constructor.


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] [Resolved] (SOLR-13622) Add FileStream Streaming Expression

2019-07-25 Thread Jason Gerlowski (JIRA)



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

Jason Gerlowski resolved SOLR-13622.

   Resolution: Fixed
Fix Version/s: 8.3

> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each 
> line of the file as a tuple.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13622) Add FileStream Streaming Expression

2019-07-25 Thread Jason Gerlowski (JIRA)



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

Jason Gerlowski commented on SOLR-13622:


I merged the initial version of this to {{master}} and {{branch_8x}}.  I only 
made two changes of note since my last post here:

* I changed the name of the expression from {{fileStream}} to {{files}}.
* I changed the chroot to be based out of a directory called 
{{$SOLR_HOME/userfiles}}.  The {{userfiles}} directory gets created if it 
doesn't exist upon Solr startup and users can put files in after that point. 

> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each 
> line of the file as a tuple.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete

2019-07-25 Thread Robert Muir (JIRA)



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

Robert Muir commented on LUCENE-8369:
-

I don't think adding esoteric functionality (like non-WGS shapes) makes any 
kind of argument to pull basic lat/lon point searching out of core.

We could add 10x more such esoteric functionality and it doesn't change a 
thing. Such core use cases should work easily for users without wading thru 
extra jars, third party dependencies, crazy licensing, or crazy class 
hierarchies.

> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially why the module existed.  Better late than never.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13622) Add FileStream Streaming Expression



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

ASF subversion and git services commented on SOLR-13622:


Commit fa9473df8feff74ddc2c00cf1d18b36e0899410b in lucene-solr's branch 
refs/heads/branch_8x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fa9473d ]

SOLR-13622: Add fileStream stream-source


> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each 
> line of the file as a tuple.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13622) Add FileStream Streaming Expression

2019-07-25 Thread ASF subversion and git services (JIRA)



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

ASF subversion and git services commented on SOLR-13622:


Commit dc8e9afff92f3ffc4081a2ecad5970eb09924a73 in lucene-solr's branch 
refs/heads/master from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=dc8e9af ]

SOLR-13622: Add fileStream stream-source


> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each 
> line of the file as a tuple.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

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

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/255/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 14576 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20190725_111048_306271466799117627447.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  Internal Error (sharedRuntime.cpp:876), pid=20169, 
tid=0x0003917b
   [junit4] #  guarantee(nm != NULL) failed: must have containing nmethod for 
implicit division-by-zero exceptions
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (8.0_201-b09) (build 
1.8.0_201-b09)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode 
bsd-amd64 )
   [junit4] # Failed to write core dump. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-core/test/J0/hs_err_pid20169.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.java.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J0: EOF 

[...truncated 1539 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/jre/bin/java 
-XX:-UseCompressedOops -XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/heapdumps -ea 
-esa -Dtests.prefix=tests -Dtests.seed=53D7894D713859C9 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=8.3.0 
-Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Dcommon.dir=/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene 
-Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/clover/db
 
-Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/tools/junit4/solr-tests.policy
 -Dtests.LUCENE_VERSION=8.3.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-core/test/J0
 
-Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-core/test/temp
 -Djunit4.childvm.id=0 -Djunit4.childvm.count=2 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true -Dtests.disableHdfs=true -Dtests.badapples=false 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=UTF-8 -classpath 
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-core/classes/test:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-test-framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/test-framework/lib/hamcrest-core-1.3.jar:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/test-framework/lib/junit4-ant-2.7.2.jar:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/test-framework/lib/opentracing-mock-0.33.0.jar:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/test-files:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/test-framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/codecs/classes/java:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-solrj/classes/java:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/build/solr-core/classes/java:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/common/lucene-analyzers-common-8.3.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-8.3.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/nori/lucene-analyzers-nori-8.3.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-8.3.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/lucene/build/codecs/lucene-codecs-8.3.0-SNAPSHOT.jar:/Users/jenkins/work

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets



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

Tomoko Uchida commented on LUCENE-8933:
---

If there are no other opinions or objections, I'd like to create a patch that 
add a validation rule to the UserDictionary.

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 160 - Still unstable

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/160/

1 tests failed.
FAILED:  
org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings

Error Message:
last stage: inconsistent endOffset at pos=1: 38 vs 44; token=andalf sser talk 
talk

Stack Trace:
java.lang.IllegalStateException: last stage: inconsistent endOffset at pos=1: 
38 vs 44; token=andalf sser talk talk
at 
__randomizedtesting.SeedInfo.seed([B7F9ED9937C42EAD:DDA252886E8A0E5E]:0)
at 
org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:146)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:746)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:657)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:559)
at 
org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:899)
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 
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 
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)




Build Log:
[...truncated 3804 lines...]
   [junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
   [junit4]   2> stage 0: andalf61<[0-8] +1> UUsser<[14-18] +1> 
talk:Gandalf61<[19-33] +1> talk<[34-3

Re: Facet count cache (Solr)

2019-07-25 Thread Michael Gibney

Thank you, David! I'll take another look at the existing per-segment caches
and hopefully create a new issue soon.
Michael

On Wed, Jul 24, 2019 at 11:54 PM David Smiley 
wrote:

> I think a new issue is appropriate, not the old one SOLR-1617 that feels
> like the reporter's wishful TODO that is underspecified.
>
> FYI on your implementation consider that Solr has some existing
> per-segment caches; one somewhere in the joins perSegment blah blah blah,
> and another inside RptWithGeometrySpatialField.  It's a bit awkward; I wish
> Solr supported per-segment caches better as a first class notion.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Jul 24, 2019 at 9:57 AM Michael Gibney 
> wrote:
>
>> I'm interested in caching facet counts, keyed to query/DocSet domain
>> (like filterCache, but caching facet counts instead of DocSets).
>>
>> Trying not to open a duplicate issue, I found SOLR-1617
>> , but I wasn't clear on
>> whether it's applicable, or whether it's about maintaining per-segment UIF
>> data structures (which could be considered a type of cache).
>>
>> I'd appreciate any guidance/suggestions on how to proceed -- revive
>> SOLR-1617, or open a new issue; thanks!
>>
>> Michael
>>
>> ps- A version of the functionality I'm interested in is implemented and
>> folded in to SOLR-13132
>>  (as a prerequisite
>> for performance on that issue). But I think I may have buried the lead by
>> including it there, since sort-by-relatedness is a relatively specialized
>> use case, and a facet cache is more generally useful. The cache as
>> implemented for SOLR-13132 is compatible across SimpleFacets and JSON
>> facets, and is segment-aware (so should be NRT-friendly). It's particularly
>> useful for high-cardinality fields and high-cardinality DocSet domains
>> (e.g., facets on a main landing page).
>>
>

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets



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

Tomoko Uchida commented on LUCENE-8933:
---

Thanks for your explanation and investigation, I agree with this policy.

bq. You don't need emojis or surrogate pairs to break this, just provide a rule 
where the length of the segmentation is greater than the input minus the 
whitespaces:

Just for confirmation, this entry works without any problem. (Here, same Emoji 
character appears both of first and second column. I think this should be 
allowed because some surrogate pair Kanjis are often used in specific 
situations like person names.)

{code:java}
UserDictionary dict = UserDictionary.open(new 
StringReader("アメ🙂カン航空,アメ🙂カン航空,アメリカンコウクウ,カスタム用語"));
JapaneseTokenizer tok = new JapaneseTokenizer(dict, true, Mode.NORMAL);
tok.setReader(new StringReader("アメリカン航空"));
tok.reset();
tok.incrementToken();
{code}

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13579) Create resource management API



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

Andrzej Bialecki  commented on SOLR-13579:
--

bq. why is the "ResourceManagerPool" class different from the 
"ResourceManagerPlugin" class?
The code in {{ResourceManagerPool}} is independent of the type of resource(s) 
that a pool can manage. I decided to leave them separate for now - perhaps at 
some point we could allow a single pool to manage several aspects of a 
component, in which case a pool could have several plugins.

Also, there can be different pools of the same type, each used for a different 
group of components that support the same management aspect. For example, for 
searcher caches we may want to eventually create separate pools for 
filterCache, queryResultCache and fieldValueCache. All of these pools would use 
the same plugin implementation {{CacheManagerPlugin}} but configured with 
different params and limits.

bq. What happens if a single ManagedResource is part of two different "pools" 
with two different ResourceManagerPlugins that give conflicting/overlapping 
instructions?

Currently this is not allowed ({{DefaultResourceManager.addResource:183}}). In 
theory, I could imagine a component to belong to more than 1 pool of the same 
type - eg. one being a global per-node pool for coarse-grained control and the 
other being a local per-core pool for fine-grained optimization.

However, at this point my head explodes thinking about all possible bad 
interactions, so the code expressly forbids it. :)

bq. does that imply that once SolrCache(s) are part of a "pool" they no longer 
have their own max size(s)?
They still do - but it's used as the starting point for proportional 
adjustments.

As I mentioned above, the exact details of how the adjustments are distributed 
among all caches are still unclear - in the current patch they are applied 
proportionally to each cache's maxSize / maxRamMB. It should be easy to add 
more complex priorities or weights - I wanted to start with something simple to 
illustrate the concept.

bq. how/where would someone specify a "preference" for ensuring that if a 
"pool" is "full" that certain resources should be managed more agressively then 
others

In the current API that would probably need to be defined somewhere between 
{{SolrCache.getResourceLimits()}} and {{CacheManagerPlugin}}, ie. the cache 
would report its "priority" as one of the limits and the plugin would know what 
to do about it.

bq. Also, FYI: with this patch, we now have 2 "ManagedResource" classes in 
solr/core that have absolutely nothing to do with each other...
Yeah, I'll rename this one to something else.

> Create resource management API
> --
>
> Key: SOLR-13579
> URL: https://issues.apache.org/jira/browse/SOLR-13579
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, 
> SOLR-13579.patch, SOLR-13579.patch
>
>
> Resource management framework API supporting the goals outlined in SOLR-13578.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets

2019-07-25 Thread Jim Ferenczi (JIRA)



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

Jim Ferenczi commented on LUCENE-8933:
--

The first argument of the dictionary rule is the original block to detect and 
the second argument is the segmentation for the block. So the rule "aaa,aa a,," 
will split the input "aaa" into two tokens "aa" and "a". When computing the 
offsets of the splitted terms in the user dictionary we assume that the 
segmentation has the same character than the input minus the whitespaces. We 
don't check that is the case so rules with broken offsets are only detected 
when they match in a token stream. You don't need emojis or surrogate pairs to 
break this, just provide a rule where the length of the segmentation is greater 
than the input minus the whitespaces:
{code:java}
UserDictionary dict = UserDictionary.open(new StringReader("aaa,,,"));
JapaneseTokenizer tok = new JapaneseTokenizer(dict, true, Mode.NORMAL);
tok.setReader(new StringReader("aaa"));
tok.reset();
tok.incrementToken();
{code}

I think we just need to validate the input and throw an exception if the 
assumption are not met at build time.



> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13579) Create resource management API

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

Andrzej Bialecki commented on SOLR-13579:
--

The main scenario that prompted this development was a need to control the
aggregated cache sizes across all cores in a CoreContainer in a multi-tenant
(uncooperative) situation. However, it seemed like a similar approach would be
applicable for controlling other runtime usage of resources in a Solr node -
hence the attempt to come up with a generic framework.

A particular component may support resource management of several of its
aspects. Eg. a {{SolrIndexSearcher}} can have a "cache" RAM usage aspect,
"mergeIO" throttling aspect, "mergeThreadCount" aspect, "queryThreadCount"
aspect, etc. Each of these aspects can be managed by a different global pool
that defines total resource limits of a given type. Currently a component can
be registered only in a single pool of a given type, in order to avoid
conflicting instructions.

In the current patch the component registration and pool creation parts are
primitive - the default pools are created statically and components are forced
to register in a dedicated pool. In the future this could be configurable - eg.
components from cores belonging to different collections may belong to
different pools with different limits / priorities.

In the following stories, there are always two aspects of resource management -
control and optimization. The control aspect ensures that the specified hard
limits are observed, while the optimization aspect ensures that each component
uses resources in an optimal way. The focus of this JIRA issue is mainly on the
control aspect, with optimization to follow later.

h2. Story 1: controlling global cache RAM usage in a Solr node
{{SolrIndexSearcher}} caches are currently configured statically, using either
item count limits or {{maxRamMB}} limits. We can only specify the limit
per-cache and then we can limit the number of cores in a node to arrive at a
hard total upper limit.

However, this is not enough because it leads to keeping the heap at the upper
limit when the actual consumption by caches might be far lesser. It'd be nice
for a more active core to be able to use more heap for caches than another core
with less traffic while ensuring that total heap usage never exceeds a given
threshold (the optimization aspect). It is also required that total heap usage
of caches doesn't exceed the max threshold to ensure proper behavior of a Solr
node (the control aspect).

In order to do this we need a control mechanism that is able to adjust
individual cache sizes per core, based on the total hard limit and the actual
current "need" of a core, defined as a combination of hit ratio, QPS, and other
arbitrary quality factors / SLA. This control mechanism also needs to be able
to forcibly reduce excessive usage (evenly? prioritized by collection's SLA?)
when the aggregated heap usage exceeds the threshold.

In terms of the proposed API this scenario would work as follows:
* a global resource pool "searcherCachesPool" is created with a single hard
limit on eg. total {{maxRamMB}}.
* this pool knows how to manage components of a "cache" type - what parameters
to monitor and what parameters to use in order to control their resource usage.
This logic is encapsulated in {{CacheManagerPlugin}}.
* all searcher caches from all cores register themselves in this pool for the
purpose of managing their "cache" aspect.
* the plugin is executed periodically to check the current resource usage of
all registered caches, using eg. the aggregated value of {{ramBytesUsed}}.
* if this aggregated value exceeds the total {{maxRamMB}} limit configured for
the pool then the plugin adjusts the {{maxRamMB}} setting of each cache in
order to reduce the total RAM consumption - currently this uses a simple
proportional formula without any history (the P part of PID), with a dead-band
in order to avoid thrashing. Also, for now, this addresses only the control
aspect (exceeding a hard threshold) and not the optimization, i.e. it doesn't
proactively reduce / increase {{maxRamMB}} based on hit rate.
* as a result of this action some of the cache content will be evicted sooner
and more aggressively than initially configured, thus freeing more RAM.
* when the memory pressure decreases the {{CacheManagerPlugin}} re-adjusts the
{{maxRamMB}} settings of each cache to the initially configured values. Again,
the current implementation of this algorithm is very simple but can be easily
improved because it's cleanly separated from implementation details of each
cache.

h2. Story 2: controlling global IO usage in a Solr node.

Similarly to the scenario above, currently we can only statically configure
merge throttling (RateLimiter) per core but we can't monitor and control

[jira] [Updated] (LUCENE-8764) Add "export all terms" feature to Luke

2019-07-25 Thread Leonardo Menezes (JIRA)



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

Leonardo Menezes updated LUCENE-8764:
-
Attachment: Screenshot 2019-07-25 13.25.23.png
Screenshot 2019-07-25 13.21.03.png
Screenshot 2019-07-25 13.20.48.png
Screenshot 2019-07-25 13.20.40.png

> Add "export all terms" feature to Luke
> --
>
> Key: LUCENE-8764
> URL: https://issues.apache.org/jira/browse/LUCENE-8764
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Tomoko Uchida
>Priority: Major
>  Labels: beginner
> Attachments: LUCENE-8764.patch, LUCENE-8764.patch, LUCENE-8764.patch, 
> Screenshot 2019-07-23 12.29.06.png, Screenshot 2019-07-24 12.35.48.png, 
> Screenshot 2019-07-24 12.36.00.png, Screenshot 2019-07-24 12.36.27.png, 
> Screenshot 2019-07-25 13.20.40.png, Screenshot 2019-07-25 13.20.48.png, 
> Screenshot 2019-07-25 13.21.03.png, Screenshot 2019-07-25 13.25.23.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/3] (There are users' requests so I 
> moved this from GitHub to Jira)
> You can browse terms in arbitrary field via Luke GUI, but in some cases 
> "exporting all terms (and optionally docids) to a file" feature would be 
> useful for further inspection. It might be similar to Solr's terms component.
> As for the user interface, "Export terms" button should be located in 
> Overview tab and/or Documents tab.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (LUCENE-8764) Add "export all terms" feature to Luke

2019-07-25 Thread Leonardo Menezes (JIRA)



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

Leonardo Menezes updated LUCENE-8764:
-
Attachment: LUCENE-8764.patch

> Add "export all terms" feature to Luke
> --
>
> Key: LUCENE-8764
> URL: https://issues.apache.org/jira/browse/LUCENE-8764
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Tomoko Uchida
>Priority: Major
>  Labels: beginner
> Attachments: LUCENE-8764.patch, LUCENE-8764.patch, LUCENE-8764.patch, 
> Screenshot 2019-07-23 12.29.06.png, Screenshot 2019-07-24 12.35.48.png, 
> Screenshot 2019-07-24 12.36.00.png, Screenshot 2019-07-24 12.36.27.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/3] (There are users' requests so I 
> moved this from GitHub to Jira)
> You can browse terms in arbitrary field via Luke GUI, but in some cases 
> "exporting all terms (and optionally docids) to a file" feature would be 
> useful for further inspection. It might be similar to Solr's terms component.
> As for the user interface, "Export terms" button should be located in 
> Overview tab and/or Documents tab.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8764) Add "export all terms" feature to Luke

2019-07-25 Thread Leonardo Menezes (JIRA)



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

Leonardo Menezes commented on LUCENE-8764:
--

Hi there,

I just added a file chooser(to choose the dir). Choosing the filename might be 
a bit trickier I guess, since its a file that doesn't exist yet. So, maybe for 
now we can keep the default filename, although allowing user to select 
destination.

I'm adding latest patch and screenshots.

Thanks :)

> Add "export all terms" feature to Luke
> --
>
> Key: LUCENE-8764
> URL: https://issues.apache.org/jira/browse/LUCENE-8764
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Tomoko Uchida
>Priority: Major
>  Labels: beginner
> Attachments: LUCENE-8764.patch, LUCENE-8764.patch, Screenshot 
> 2019-07-23 12.29.06.png, Screenshot 2019-07-24 12.35.48.png, Screenshot 
> 2019-07-24 12.36.00.png, Screenshot 2019-07-24 12.36.27.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/3] (There are users' requests so I 
> moved this from GitHub to Jira)
> You can browse terms in arbitrary field via Luke GUI, but in some cases 
> "exporting all terms (and optionally docids) to a file" feature would be 
> useful for further inspection. It might be similar to Solr's terms component.
> As for the user interface, "Export terms" button should be located in 
> Overview tab and/or Documents tab.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-11.0.3) - Build # 5271 - Failure!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5271/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 64750 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1009277159
 [ecj-lint] Compiling 69 source files to 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1009277159
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 28)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 29)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 182)
 [ecj-lint] c = getFromJndi(initProps, jndiName);
 [ecj-lint] ^^^
 [ecj-lint] The method getFromJndi(Properties, String) from the type new 
Callable(){} refers to the missing type NamingException
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 245)
 [ecj-lint] private Connection getFromJndi(final Properties initProps, 
final String jndiName) throws NamingException,
 [ecj-lint] 
 ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint]   ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6 problems (6 errors)

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:634: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:101: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build.xml:651: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-build.xml:479: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2009:
 The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2048:
 Compile failed; see the compiler error output for details.

Total time: 149 minutes 2 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/Users/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=/Users/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=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

---

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets



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

Adrien Grand commented on LUCENE-8933:
--

Ah, thanks for digging [~tomoko] and [~danmuzi]. I simplified Tomoko's 
recreation a bit more:

{code:java}
UserDictionary dict = UserDictionary.open(new 
StringReader("アメリカン航空,アメ🙂カン航空,アメリカンコウクウ,カスタム用語"));
JapaneseTokenizer tok = new JapaneseTokenizer(dict, true, Mode.NORMAL);
tok.setReader(new StringReader("アメリカン航空"));
tok.reset();
tok.incrementToken();
{code}

Tomoko, I wonder that the fact that the issue doesn't occur when the emoji is 
at other positions might be due to the fact that the Position class initializes 
its buffers' sizes to 8?

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8929) Early Terminating CollectorManager

2019-07-25 Thread Atri Sharma (JIRA)



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

Atri Sharma commented on LUCENE-8929:
-

Ok, so I have been working on this and am wondering what the definition 
(parameter) of a globally competitive hit be. Should it be the largest of the 
worst accepted hit across all collectors, and all collectors use that as the 
minimum threshold when filtering further hits?

> Early Terminating CollectorManager
> --
>
> Key: LUCENE-8929
> URL: https://issues.apache.org/jira/browse/LUCENE-8929
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We should have an early terminating collector manager which accurately tracks 
> hits across all of its collectors and determines when there are enough hits, 
> allowing all the collectors to abort.
> The options for the same are:
> 1) Shared total count : Global "scoreboard" where all collectors update their 
> current hit count. At the end of each document's collection, collector checks 
> if N > threshold, and aborts if true
> 2) State Reporting Collectors: Collectors report their total number of counts 
> collected periodically using a callback mechanism, and get a proceed or abort 
> decision.
> 1) has the overhead of synchronization in the hot path, 2) can collect 
> unnecessary hits before aborting.
> I am planning to work on 2), unless objections



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (SOLR-13545) ContentStreamUpdateRequest no longer closes stream



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

Mikhail Khludnev edited comment on SOLR-13545 at 7/25/19 9:51 AM:
--

note 
https://issues.apache.org/jira/browse/SOLR-13637?focusedCommentId=16892277&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16892277


was (Author: mkhludnev):
spawn SOLR-13651

> ContentStreamUpdateRequest no longer closes stream
> --
>
> Key: SOLR-13545
> URL: https://issues.apache.org/jira/browse/SOLR-13545
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.4, 7.5, 7.6, 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.1.1
> Environment: Windows - file locking may not cause a visible failure 
> on Linux?
>Reporter: Colvin Cowie
>Priority: Major
> Fix For: 8.2
>
> Attachments: ContentStreamUpdateRequestBug.java, SOLR-13545.patch, 
> SOLR-13545.patch, SOLR-13545.patch
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Since the change made in SOLR-12142 _ContentStreamUpdateRequest_ no longer 
> closes the stream that it opens. Therefore if streaming a file, it cannot be 
> deleted until the process exits.
>  
> {code:java}
> @Override
>   public RequestWriter.ContentWriter getContentWriter(String expectedType) {
>     if (contentStreams == null || contentStreams.isEmpty() || 
> contentStreams.size() > 1) return null;
>     ContentStream stream = contentStreams.get(0);
>     return new RequestWriter.ContentWriter() {
>       @Override
>       public void write(OutputStream os) throws IOException {
>         IOUtils.copy(stream.getStream(), os);
>       }
>       @Override
>       public String getContentType() {
>         return stream.getContentType();
>       }
>     };
>   }
> {code}
> IOUtils.copy will not close the stream. Adding a close to the write(), is 
> enough to "fix" it for the test case I've attached, e.g.
>  
> {code:java}
>       @Override
>       public void write(OutputStream os) throws IOException {
>   final InputStream innerStream = stream.getStream();
>   try {
>     IOUtils.copy(innerStream, os);
>   } finally {
>     IOUtils.closeQuietly(innerStream);
>   }
>       }
> {code}
>  
> I don't know whether any other streaming classes have similar issues
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Closed] (SOLR-13651) BasicAuthIntegrationTest.testBasicAuth failure caused by No contentStream in .doEdit(SecurityConfHandler.java:103)



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

Mikhail Khludnev closed SOLR-13651.
---

> BasicAuthIntegrationTest.testBasicAuth failure caused by No contentStream in 
> .doEdit(SecurityConfHandler.java:103)
> --
>
> Key: SOLR-13651
> URL: https://issues.apache.org/jira/browse/SOLR-13651
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: 8.2
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Test fails on v2 auth request. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-13651) BasicAuthIntegrationTest.testBasicAuth failure caused by No contentStream in .doEdit(SecurityConfHandler.java:103)



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

Mikhail Khludnev resolved SOLR-13651.
-
Resolution: Duplicate

Thanks, [~noble.paul]

> BasicAuthIntegrationTest.testBasicAuth failure caused by No contentStream in 
> .doEdit(SecurityConfHandler.java:103)
> --
>
> Key: SOLR-13651
> URL: https://issues.apache.org/jira/browse/SOLR-13651
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: 8.2
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Test fails on v2 auth request. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13651) BasicAuthIntegrationTest.testBasicAuth failure caused by No contentStream in .doEdit(SecurityConfHandler.java:103)

2019-07-25 Thread Noble Paul (JIRA)



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

Noble Paul commented on SOLR-13651:
---

it's already fixed as a part of SOLR-13637

> BasicAuthIntegrationTest.testBasicAuth failure caused by No contentStream in 
> .doEdit(SecurityConfHandler.java:103)
> --
>
> Key: SOLR-13651
> URL: https://issues.apache.org/jira/browse/SOLR-13651
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: 8.2
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Test fails on v2 auth request. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13651) BasicAuthIntegrationTest.testBasicAuth failure caused by No contentStream in .doEdit(SecurityConfHandler.java:103)



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

Mikhail Khludnev commented on SOLR-13651:
-

https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/911/console

Reproduces on {{branch_8x}}
{code}
   [junit4]   2> 26528 INFO  
(TEST-BasicAuthIntegrationTest.testBasicAuth-seed#[B292FDDCA6F4D6F2]) [ ] 
o.a.h.i.e.RetryExec I/O exception (org.apache.http.NoHttpResponseException) 
caught when processing request to {s}->https://127.0.0.1:40505: The target 
server failed to respond
   [junit4]   2> 26528 INFO  
(TEST-BasicAuthIntegrationTest.testBasicAuth-seed#[B292FDDCA6F4D6F2]) [ ] 
o.a.h.i.e.RetryExec Retrying request to {s}->https://127.0.0.1:40505
   [junit4]   2> 26588 INFO  (qtp1361614499-740) [n:127.0.0.1:40505_solr ] 
o.a.s.s.HttpSolrCall [admin] webapp=null path=/cluster/security/authentication 
params={} status=0 QTime=0
   [junit4]   2> 26601 ERROR (qtp1952522099-600) [n:127.0.0.1:44583_solr ] 
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: No 
contentStream
   [junit4]   2>at 
org.apache.solr.handler.admin.SecurityConfHandler.doEdit(SecurityConfHandler.java:103)
   [junit4]   2>at 
org.apache.solr.handler.admin.SecurityConfHandler.handleRequestBody(SecurityConfHandler.java:85)
   [junit4]   2>at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
   [junit4]   2>at 
org.apache.solr.api.ApiBag$ReqHandlerToApi.call(ApiBag.java:247)
   [junit4]   2>at 
org.apache.solr.api.V2HttpCall.handleAdmin(V2HttpCall.java:341)
..
   [junit4]   2> 26601 INFO  (qtp1952522099-600) [n:127.0.0.1:44583_solr ] 
o.a.s.s.HttpSolrCall [admin] webapp=null path=/cluster/security/authentication 
params={wt=javabin&version=2} status=400 QTime=0
..
   [junit4] FAILURE 6.82s J2 | BasicAuthIntegrationTest.testBasicAuth <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<401> but 
was:<400>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([B292FDDCA6F4D6F2:EFC8BCE02A75588]:0)
   [junit4]>at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:151)

ant test  -Dtestcase=BasicAuthIntegrationTest -Dtests.method=testBasicAuth 
-Dtests.seed=B292FDDCA6F4D6F2 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=et-EE -Dtests.timezone=Pacific/Easter 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
{code}



> BasicAuthIntegrationTest.testBasicAuth failure caused by No contentStream in 
> .doEdit(SecurityConfHandler.java:103)
> --
>
> Key: SOLR-13651
> URL: https://issues.apache.org/jira/browse/SOLR-13651
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: 8.2
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Test fails on v2 auth request. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13545) ContentStreamUpdateRequest no longer closes stream



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

Mikhail Khludnev commented on SOLR-13545:
-

spawn SOLR-13651

> ContentStreamUpdateRequest no longer closes stream
> --
>
> Key: SOLR-13545
> URL: https://issues.apache.org/jira/browse/SOLR-13545
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.4, 7.5, 7.6, 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.1.1
> Environment: Windows - file locking may not cause a visible failure 
> on Linux?
>Reporter: Colvin Cowie
>Priority: Major
> Fix For: 8.2
>
> Attachments: ContentStreamUpdateRequestBug.java, SOLR-13545.patch, 
> SOLR-13545.patch, SOLR-13545.patch
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Since the change made in SOLR-12142 _ContentStreamUpdateRequest_ no longer 
> closes the stream that it opens. Therefore if streaming a file, it cannot be 
> deleted until the process exits.
>  
> {code:java}
> @Override
>   public RequestWriter.ContentWriter getContentWriter(String expectedType) {
>     if (contentStreams == null || contentStreams.isEmpty() || 
> contentStreams.size() > 1) return null;
>     ContentStream stream = contentStreams.get(0);
>     return new RequestWriter.ContentWriter() {
>       @Override
>       public void write(OutputStream os) throws IOException {
>         IOUtils.copy(stream.getStream(), os);
>       }
>       @Override
>       public String getContentType() {
>         return stream.getContentType();
>       }
>     };
>   }
> {code}
> IOUtils.copy will not close the stream. Adding a close to the write(), is 
> enough to "fix" it for the test case I've attached, e.g.
>  
> {code:java}
>       @Override
>       public void write(OutputStream os) throws IOException {
>   final InputStream innerStream = stream.getStream();
>   try {
>     IOUtils.copy(innerStream, os);
>   } finally {
>     IOUtils.closeQuietly(innerStream);
>   }
>       }
> {code}
>  
> I don't know whether any other streaming classes have similar issues
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Created] (SOLR-13651) BasicAuthIntegrationTest.testBasicAuth failure caused by No contentStream in .doEdit(SecurityConfHandler.java:103)

Mikhail Khludnev created SOLR-13651:
---

 Summary: BasicAuthIntegrationTest.testBasicAuth failure caused by 
No contentStream in .doEdit(SecurityConfHandler.java:103)
 Key: SOLR-13651
 URL: https://issues.apache.org/jira/browse/SOLR-13651
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Authentication
Affects Versions: 8.2
Reporter: Mikhail Khludnev


Test fails on v2 auth request. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets



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

Tomoko Uchida commented on LUCENE-8933:
---

The surrogate pair Emoji character 🙂  included in the user dictionary is 
problematic. Interestingly, it does not cause the error if it appears at the 
first column (for "normal" mode segmentation).

KoreanTokenizer could have same issue?

> JapaneseTokenizer creates Token objects with corrupt offsets
> 
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
>
> An Elasticsearch user reported the following stack trace when parsing 
> synonyms. It looks like the only reason why this might occur is if the offset 
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>  
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
>  ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f - 
> nknize - 2018-12-07 14:44:20]
> at 
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
>  ~[?:?]
> at 
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
>  ~[lucene-analyzers-common-7.6.0.jar:7.6.0 
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at 
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
>  ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1909 - Still Failing