[jira] [Created] (SOLR-11864) API inconsistency in create and delete collection

[Hem (JIRA)]

Hem created SOLR-11864:
--

 Summary: API inconsistency in create and delete collection
 Key: SOLR-11864
 URL: https://issues.apache.org/jira/browse/SOLR-11864
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: v2 API
Affects Versions: 5.3.1
Reporter: Hem


When i create a collection through java using the client jar, if there is a 
space following the collection name, the collection gets created.

But when i try to delete the same collection with the space through delete API 
from the browser I get the error of collection not found.

Steps to reproduce:
 # Create a collection through client with collection name having a space.
 # Try to delete it using collection delete API through browser

Another issue is the collection name with space at the end, the shards are 
always in recovery state and after some time shifts to degraded state.

The API should be able to delete the collection. And if collection name does 
not require the space then there should be an internal trim or a validation 
error thrown.



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

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

Solr block join query not giving results

[Aashish Agarwal]

Hi,

I am using block join query to get parent object using filter on child. But
when the number of results are large than the query fails with
ArrayIndexOutOfBoundException. e.g in range query price:[0 TO 20] fails but
price[0 TO 10], price:[10 TO 20] works fine. I am using solr 4.6.0.

Thanks,
Aashish

[jira] [Updated] (SOLR-11807) Remove special handling for maxShardsPerNode=-1

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11807:
-
Priority: Minor  (was: Major)

> Remove special handling for maxShardsPerNode=-1
> ---
>
> Key: SOLR-11807
> URL: https://issues.apache.org/jira/browse/SOLR-11807
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11807.patch, SOLR-11807.patch
>
>
> Today we can never restore the cloud example gettingstarted collection 
> because it sets maxShardsPerNode=-1 . We have special handling for -1 in 
> CreateCollectionCmd but not in RestoreCmd.
> Today RestoreCmd does has this check and it fails to restore the collection
> {code}
> if ((numShards * totalReplicasPerShard) > (availableNodeCount * 
> maxShardsPerNode)) {
>   throw new SolrException(ErrorCode.BAD_REQUEST,
>   String.format(Locale.ROOT, "Solr cloud with available number of 
> nodes:%d is insufficient for"
>   + " restoring a collection with %d shards, total replicas per 
> shard %d and maxShardsPerNode %d."
>   + " Consider increasing maxShardsPerNode value OR number of 
> available nodes.",
>   availableNodeCount, numShards, totalReplicasPerShard, 
> maxShardsPerNode));
> }
> {code}
> Steps to reproduce:
> Steps to reproduce:
> 1. ./bin/solr start -e cloud -noprompt : This creates a 2 node cluster and a 
> gettingstarted collection which 2X2
> 2. Added 4 docs (id=1,2,3,4) with commit=true and openSearcher=true (default)
> 3. Call backup: 
> http://localhost:8983/solr/admin/collections?action=BACKUP=gettingstarted_backup=gettingstarted=/Users/varunthacker/solr-7.1.0
> 4. Call restore:
> http://localhost:8983/solr/admin/collections?action=restore=gettingstarted_backup=restore_gettingstarted=/Users/varunthacker/solr-7.1.0



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

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

[jira] [Commented] (SOLR-8327) SolrDispatchFilter is not caching new state format, which results in live fetch from ZK per request if node does not contain core from collection

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8327:
--

[~varunthacker] We really can't let every node listen to, get notified and 
update the state of every single collection if we want to scale to 1's of 
collections. So, this was a deliberate design choice

 

[~ichattopadhyaya]

The following code snippet would fetch the state and parse it irrespective of 
whether the state is updated.  It should download the changed state  only if 
the znode version is changed
{code:java}

@Override
public synchronized DocCollection get() {
 gets.incrementAndGet();
 if (lastUpdateTime < 0 || System.nanoTime() - lastUpdateTime > 
LAZY_CACHE_TIME) {
 cachedDocCollection = getCollectionLive(ZkStateReader.this, collName);
 lastUpdateTime = System.nanoTime();
 }
 return cachedDocCollection;
}
{code}

> SolrDispatchFilter is not caching new state format, which results in live 
> fetch from ZK per request if node does not contain core from collection
> -
>
> Key: SOLR-8327
> URL: https://issues.apache.org/jira/browse/SOLR-8327
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Jessica Cheng Mallet
>Assignee: Varun Thacker
>Priority: Major
>  Labels: solrcloud
> Attachments: SOLR-8327.patch
>
>
> While perf testing with non-solrj client (request can be sent to any solr 
> node), we noticed a huge amount of data from Zookeeper in our tcpdump (~1G 
> for 20 second dump). From the thread dump, we noticed this:
> java.lang.Object.wait (Native Method)
> java.lang.Object.wait (Object.java:503)
> org.apache.zookeeper.ClientCnxn.submitRequest (ClientCnxn.java:1309)
> org.apache.zookeeper.ZooKeeper.getData (ZooKeeper.java:1152)
> org.apache.solr.common.cloud.SolrZkClient$7.execute (SolrZkClient.java:345)
> org.apache.solr.common.cloud.SolrZkClient$7.execute (SolrZkClient.java:342)
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation 
> (ZkCmdExecutor.java:61)
> org.apache.solr.common.cloud.SolrZkClient.getData (SolrZkClient.java:342)
> org.apache.solr.common.cloud.ZkStateReader.getCollectionLive 
> (ZkStateReader.java:841)
> org.apache.solr.common.cloud.ZkStateReader$7.get (ZkStateReader.java:515)
> org.apache.solr.common.cloud.ClusterState.getCollectionOrNull 
> (ClusterState.java:175)
> org.apache.solr.common.cloud.ClusterState.getLeader (ClusterState.java:98)
> org.apache.solr.servlet.HttpSolrCall.getCoreByCollection 
> (HttpSolrCall.java:784)
> org.apache.solr.servlet.HttpSolrCall.init (HttpSolrCall.java:272)
> org.apache.solr.servlet.HttpSolrCall.call (HttpSolrCall.java:417)
> org.apache.solr.servlet.SolrDispatchFilter.doFilter 
> (SolrDispatchFilter.java:210)
> org.apache.solr.servlet.SolrDispatchFilter.doFilter 
> (SolrDispatchFilter.java:179)
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter 
> (ServletHandler.java:1652)
> org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:585)
> org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143)
> org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:577)
> org.eclipse.jetty.server.session.SessionHandler.doHandle 
> (SessionHandler.java:223)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle 
> (ContextHandler.java:1127)
> org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:515)
> org.eclipse.jetty.server.session.SessionHandler.doScope 
> (SessionHandler.java:185)
> org.eclipse.jetty.server.handler.ContextHandler.doScope 
> (ContextHandler.java:1061)
> org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle 
> (ContextHandlerCollection.java:215)
> org.eclipse.jetty.server.handler.HandlerCollection.handle 
> (HandlerCollection.java:110)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle 
> (HandlerWrapper.java:97)
> org.eclipse.jetty.server.Server.handle (Server.java:499)
> org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:310)
> org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:257)
> org.eclipse.jetty.io.AbstractConnection$2.run (AbstractConnection.java:540)
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob 
> (QueuedThreadPool.java:635)
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run 
> (QueuedThreadPool.java:555)
> java.lang.Thread.run (Thread.java:745)
> Looks like SolrDispatchFilter doesn't have caching similar to the 
> collectionStateCache in CloudSolrClient, so if the node doesn't know about a 
> collection in the new state format, it just live-fetch it from 

[jira] [Commented] (LUCENE-7110) Add Shape Support to BKD (extend to an R*/X-Tree data structure)

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7110:
--

Nick, how would you compare your proposed approach with what 
lucene-spatial-extras SpatialPrefixTree does with the leaf node differentiator? 
 I didn't fully understand your proposal above as it requires in-depth 
knowledge of the Points implementation code. The SpatialPrefixTree trailing 
"leaf" byte concept could, I imagine in theory, be added to the Points 
internals and not be very invasive/disruptive.

I think coordinate system wrapping could be handled separately and isn't 
strictly required.

One way to introduce the feature without fully committing to it (at first) is 
to have query/index intermediate code cast the underlying PointsFormat to an 
expected subclass with methods for these shapes.  That's how the PointsAPI 
itself came into being – by casting the DocValuesFormat.
{quote}An alternative would be to add something like a rangeType property to 
IndexableFieldType and modify the existing Point codec to handle range encoding 
and coordinate system wrapping but I think that's too big of a risky hack.
{quote}
I agree; this is too advanced/specialized.  Perhaps in time as we feel out its 
impact.
{quote}GeoAPI
{quote}
Is that an ElasticSearch thing?

> Add Shape Support to BKD (extend to an R*/X-Tree data structure)
> 
>
> Key: LUCENE-7110
> URL: https://issues.apache.org/jira/browse/LUCENE-7110
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Priority: Major
>
> I've been tinkering with this off and on for a while and its showing some 
> promise so I'm going to open an issue to (eventually) add this feature to a 
> future release.
> R*/X-Tree is a data structure designed to support Shapes (2D, 3D, nD) where, 
> like the internal node, the key for each leaf node is the Minimum Bounding 
> Range (MBR - sometimes "incorrectly" referred to as Minimum Bounding 
> Rectangle) of the shape. Inserting a shape then boils down to the best way of 
> optimizing the tree structure. This optimization is driven by a set of 
> criteria for choosing the appropriate internal key (e.g., minimizing overlap 
> between siblings, maximizing "squareness", minimizing area, maximizing space 
> usage). Query is then (a bit oversimplified) a two-phase process:
>  * recurse each branch that overlaps with the MBR of the query shape
>  * compute the relation with the leaf node(s) - in higher dimensions (3+) 
> this becomes an increasingly difficult computational geometry problem
> The current BKD implementation is a special simplified case of an R*/X tree 
> where, for Point data, it is always guaranteed there will never be overlap 
> between sibling nodes (because you're using the point data as the keys). By 
> exploiting this property the tree algorithms (split, merge, etc) are 
> relatively cheap (hence their performance boost over postings based 
> numerics). By modifying the key data, and extending the tree generation 
> algorithms BKD logic can be extended to support Shape data using the MBR as 
> the Key and modifying split and merge based on the criteria needed for 
> optimizing a shape-based data structure.
> The initial implementation (based on limitations of the GeoAPI) will support 
> 2D shapes only. Once the GeoAPI can performantly handle 3D shapes the change 
> is relatively trivial to add the third dimension to the tree generation code.
> Like everything else, this feature will be created in sandbox and, once 
> mature, will graduate (likely to lucene-spatial or lucene-spatial-extras 
> depending on the library needs).



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

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1450 - Failure

[Apache Jenkins Server]

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

10 tests failed.
FAILED:  
org.apache.lucene.classification.CachingNaiveBayesClassifierTest.testPerformance

Error Message:
evaluation took more than 1m: 67s

Stack Trace:
java.lang.AssertionError: evaluation took more than 1m: 67s
at 
__randomizedtesting.SeedInfo.seed([595E05B5607CAA2A:9EBFF7970BC89285]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.lucene.classification.CachingNaiveBayesClassifierTest.testPerformance(CachingNaiveBayesClassifierTest.java:111)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.lucene.index.TestIndexWriterOnVMError.testCheckpoint

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([3A0AB42C265184EF]:0)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterOnVMError

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([3A0AB42C265184EF]:0)


FAILED:  org.apache.solr.cloud.TestTlogReplica.testCreateDelete 

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 1190 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1190/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at 
https://127.0.0.1:43399/solr/awhollynewcollection_0_shard2_replica_n2: 
ClusterState says we are the leader 
(https://127.0.0.1:43399/solr/awhollynewcollection_0_shard2_replica_n2), but 
locally we don't think so. Request came from null

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at 
https://127.0.0.1:43399/solr/awhollynewcollection_0_shard2_replica_n2: 
ClusterState says we are the leader 
(https://127.0.0.1:43399/solr/awhollynewcollection_0_shard2_replica_n2), but 
locally we don't think so. Request came from null
at 
__randomizedtesting.SeedInfo.seed([1C0E541453B71943:547B20A0558436D6]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:550)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1013)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:462)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4390 - Unstable!

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Unexpected number of elements in the group for intGSF: 8

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 8
at 
__randomizedtesting.SeedInfo.seed([726A7A4CCD914F55:E9D1141480C97D0B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:377)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest.testSimple

Error Message:
IOException occured when talking to server at: https://127.0.0.1:53511/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to 

[jira] [Comment Edited] (SOLR-11592) add another language detector using OpenNLP

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-11592 at 1/17/18 4:01 AM:


[~koji], I've attached a modified version of your patch that I think is ready 
to go, including ref guide docs, a {{CHANGES.txt}} entry, and tests; tests and 
precommit pass for me.  If you have time I'd appreciate a review.

Notable changes from the previous version of the patch:
 * Added target {{train-test-models}} to the langid contrib's {{build.xml}}.  
This downloads Leipzig corpora data files for five languages, extracts the data 
required for OpenNLP to train a model, then trains a test model.  The resulting 
model is included in the patch.
 * Added tests that use the test model.
 * Automatically convert from the 3-letter ISO 639-3 codes provided by the 
OpenNLP model into the corresponding 2-letter ISO 639-1 codes, to match the 
other two langid implementations.
 * Modified the update processor factory to interrogate the "invariants" and 
"defaults" config sections for the {{langid.model}} param.


was (Author: steve_rowe):
[~koji], I've attached a modified version of your patch that I think is ready 
to go, including ref guide docs, a {{CHANGES.txt}} entry, and tests; tests and 
precommit pass for me.  If you have time I'd appreciate a review.

Notable changes from the previous version of the patch:
 * Added target {{train-test-models}} to the langid contrib's {{build.xml}}.  
This downloads Leipzig corpora data files for five languages, extracts the data 
required for OpenNLP to train a model, then trains a test model.  The resulting 
model is included in the patch.
 * Added tests that use the test model.
 * Automatically convert from the 3-letter ISO 639-3 codes provided by the 
OpenNLP model into the corresponding 2-letter ISO 639-1 codes, to match the 
other two langid implementations.
 * Modified the update process factory to interrogate the "invariants" and 
"defaults" config sections for the {{langid.model}} param.

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch, SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



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

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

[jira] [Commented] (SOLR-11592) add another language detector using OpenNLP

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11592:
---

A note about model licensing: 

I intentionally did not include OpenNLP's pre-trained model in the patch, 
because the Leipzig corpora[1] were used to train the model.  The Leipzig 
corpora's license is CC BY-NC 4.0[2], which is on Apache's Category B list[3]; 
I think this means the Solr project could redistribute the OpenNLP pre-trained 
model, but I am uncertain.

For testing, a model is produced from a small subset of the same source data.  
I don't think we need to include licensing info for this test model derived 
from Leipzig corpora data, but I'm open to other perspectives.

[1] Leipzig corpora: http://wortschatz.uni-leipzig.de/en/download/
[2] Leipzig corpora Terms of Usage: http://wortschatz.uni-leipzig.de/en/usage
[3] Apache "Category B" 3rd party licenses: 
https://www.apache.org/legal/resolved.html#category-b

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch, SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2260 - Unstable

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  
org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState

Error Message:
expected:<27> but was:<28>

Stack Trace:
java.lang.AssertionError: expected:<27> but was:<28>
at 
__randomizedtesting.SeedInfo.seed([DE3B19B2F101D8D9:8046BB4C551C9124]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState(TestLeaderInitiatedRecoveryThread.java:115)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Comment Edited] (SOLR-11592) add another language detector using OpenNLP

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-11592 at 1/17/18 3:38 AM:


[~koji], I've attached a modified version of your patch that I think is ready 
to go, including ref guide docs, a {{CHANGES.txt}} entry, and tests; tests and 
precommit pass for me.  If you have time I'd appreciate a review.

Notable changes from the previous version of the patch:
 * Added target {{train-test-models}} to the langid contrib's {{build.xml}}.  
This downloads Leipzig corpora data files for five languages, extracts the data 
required for OpenNLP to train a model, then trains a test model.  The resulting 
model is included in the patch.
 * Added tests that use the test model.
 * Automatically convert from the 3-letter ISO 639-3 codes provided by the 
OpenNLP model into the corresponding 2-letter ISO 639-1 codes, to match the 
other two langid implementations.
 * Modified the update process factory to interrogate the "invariants" and 
"defaults" config sections for the {{langid.model}} param.


was (Author: steve_rowe):
[~koji], I've attached a modified version of your patch that I think is ready 
to go, including ref guide docs, a {{CHANGES.txt}} entry, and tests; tests and 
precommit pass for me.  If you have time I'd appreciate a review.

Notable changes from the previous version of the patch:
 * Added target {{train-test-models}} to the langid contrib's {{build.xml}}.  
This downloads Leipzip corpora data files for five languages, extracts the data 
required for OpenNLP to train a model, then trains a test model.  The resulting 
model is included in the patch.
 * Added tests that use the test model.
 * Automatically convert from the 3-letter ISO 639-3 codes provided by the 
OpenNLP model into the corresponding 2-letter ISO 639-1 codes, to match the 
other two langid implementations.
 * Modified the update process factory to interrogate the "invariants" and 
"defaults" config sections for the {{langid.model}} param.

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch, SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



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

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

[jira] [Comment Edited] (SOLR-11592) add another language detector using OpenNLP

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-11592 at 1/17/18 3:37 AM:


[~koji], I've attached a modified version of your patch that I think is ready 
to go, including ref guide docs, a {{CHANGES.txt}} entry, and tests; tests and 
precommit pass for me.  If you have time I'd appreciate a review.

Notable changes from the previous version of the patch:
 * Added target {{train-test-models}} to the langid contrib's {{build.xml}}.  
This downloads Leipzip corpora data files for five languages, extracts the data 
required for OpenNLP to train a model, then trains a test model.  The resulting 
model is included in the patch.
 * Added tests that use the test model.
 * Automatically convert from the 3-letter ISO 639-3 codes provided by the 
OpenNLP model into the corresponding 2-letter ISO 639-1 codes, to match the 
other two langid implementations.
 * Modified the update process factory to interrogate the "invariants" and 
"defaults" config sections for the {{langid.model}} param.


was (Author: steve_rowe):
[~koji], I've attached a modified version of your patch that I think is ready 
to go, including ref guide docs, a {{CHANGES.txt}} entry, and tests; tests and 
precommit pass for me.  If you have time I'd appreciate a review.

Notable changes from the previous version of the patch:
 * Added {{test-train-models}} target to the langid contrib's {{build.xml}}.  
This downloads Leipzip corpora data files for five languages, extracts the data 
required for OpenNLP to train a model, then trains a test model.  The resulting 
model is included in the patch.
 * Added tests that use the test model.
 * Automatically convert from the 3-letter ISO 639-3 codes provided by the 
OpenNLP model into the corresponding 2-letter ISO 639-1 codes, to match the 
other two langid implementations.
 * Modified the update process factory to interrogate the "invariants" and 
"defaults" config sections for the {{langid.model}} param.

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch, SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



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

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

[jira] [Commented] (SOLR-11592) add another language detector using OpenNLP

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11592:
---

[~koji], I've attached a modified version of your patch that I think is ready 
to go, including ref guide docs, a {{CHANGES.txt}} entry, and tests; tests and 
precommit pass for me.  If you have time I'd appreciate a review.

Notable changes from the previous version of the patch:
 * Added {{test-train-models}} target to the langid contrib's {{build.xml}}.  
This downloads Leipzip corpora data files for five languages, extracts the data 
required for OpenNLP to train a model, then trains a test model.  The resulting 
model is included in the patch.
 * Added tests that use the test model.
 * Automatically convert from the 3-letter ISO 639-3 codes provided by the 
OpenNLP model into the corresponding 2-letter ISO 639-1 codes, to match the 
other two langid implementations.
 * Modified the update process factory to interrogate the "invariants" and 
"defaults" config sections for the {{langid.model}} param.

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch, SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



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

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

[jira] [Updated] (SOLR-11592) add another language detector using OpenNLP

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11592:
--
Attachment: SOLR-11592.patch

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch, SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([736A569B000EB61C:FB3E6941AEF2DBE4]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:915)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:612)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
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:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-11810) Upgrade Jetty to 9.4.8

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11810:
---

The \{{CHANGES.txt}} entry for this change was placed in the "New Features" 
section, but I think it belongs elsewhere, probably "Other Changes".

> Upgrade Jetty to 9.4.8
> --
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-11810.patch, SOLR-11810.patch, SOLR-11810.patch, 
> SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



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

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

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.1) - Build # 405 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/405/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([60DC3FDEA310E9CF:E88800040DEC8437]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:915)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:612)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
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:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (SOLR-11459) AddUpdateCommand#prevVersion is not cleared which may lead to problem for in-place updates of non existed documents

[Andrey Kudryavtsev (JIRA)]

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

Andrey Kudryavtsev edited comment on SOLR-11459 at 1/17/18 2:27 AM:


Hope to fix this one. 

The test is not ideal, it will fail without "prevVersion = -1" cause of there 
doc with id = 2 will not present on every replica after in-place update. But as 
there is TestInPlaceUpdatesStandalone#testDVUpdatesWithDelete to check that 
in-place update for non existed docs will result in a doc creation, I think 
it's ok to have it's distributed analog. 

 


was (Author: werder):
Hope to fix this one. 

The test is not ideal, it will fail without 
prevVersion = -1;
cause of there doc with id = 2 will not present on every replica after in-place 
update. But as there is TestInPlaceUpdatesStandalone#testDVUpdatesWithDelete to 
check that in-place update for non existed docs will result in a doc creation, 
I think it's ok to have it's distributed analog. 

 

> AddUpdateCommand#prevVersion is not cleared which may lead to problem for 
> in-place updates of non existed documents
> ---
>
> Key: SOLR-11459
> URL: https://issues.apache.org/jira/browse/SOLR-11459
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
>
> I have a 1_shard / *m*_replicas SolrCloud cluster with Solr 6.6.0 and run 
> batches of 5 - 10k in-place updates from time to time. 
> Once I noticed that job "hangs" - it started and couldn't finish for a a 
> while.
> Logs were full of messages like:
> {code} Missing update, on which current in-place update depends on, hasn't 
> arrived. id=__, looking for version=___, last found version=0"  {code}
> {code} 
> Tried to fetch document ___ from the leader, but the leader says document has 
> been deleted. Deleting the document here and skipping this update: Last found 
> version: 0, was looking for: ___",24,0,"but the leader says document has been 
> deleted. Deleting the document here and skipping this update: Last found 
> version: 0
> {code}
> Further analysis shows that:
> * There are 100-500 updates for non-existed documents among other updates 
> (something that I have to deal with)
> * Leader receives bunch of updates and executes this updates one by one. 
> {{JavabinLoader}} which is used by processing documents reuses same instance 
> of {{AddUpdateCommand}} for every update and just [clearing its state at the 
> end|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99].
>  Field [AddUpdateCommand#prevVersion| 
> https://github.com/apache/lucene-solr/blob/6396cb759f8c799f381b0730636fa412761030ce/solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java#L76]
>  is not cleared.   
> * In case of update is in-place update, but specified document does not 
> exist, this update is processed as a regular atomic update (i.e. new doc is 
> created), but {{prevVersion}} is used as a {{distrib.inplace.prevversion}} 
> parameter in sequential calls to every slave in DistributedUpdateProcessor. 
> {{prevVersion}} wasn't cleared, so it may contain version from previous 
> processed update.
> * Slaves checks it's own version of documents which is 0 (cause doc does not 
> exist), slave thinks that some updates were missed and spends 5 seconds in 
> [DistributedUpdateProcessor#waitForDependentUpdates|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99]
>  waiting for missed updates (no luck) and also tries to get "correct" version 
> from leader (no luck as well) 
> * So update for non existed document costs *m* * 5 sec each
> I workarounded this by explicit check of doc existence, but it probably 
> should be fixed.
> Obviously first guess is that  prevVersion should be cleared in 
> {{AddUpdateCommand#clear}}, but have no clue how to test it.
> {code}
> +++ solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java   
> (revision )
> @@ -78,6 +78,7 @@
>   updateTerm = null;
>   isLastDocInBatch = false;
>   version = 0;
> + prevVersion = -1;
> }
> {code}



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

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

[jira] [Commented] (SOLR-11459) AddUpdateCommand#prevVersion is not cleared which may lead to problem for in-place updates of non existed documents

[Andrey Kudryavtsev (JIRA)]

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

Andrey Kudryavtsev commented on SOLR-11459:
---

Hope to fix this one. 

The test is not ideal, it will fail without 
prevVersion = -1;
cause of there doc with id = 2 will not present on every replica after in-place 
update. But as there is TestInPlaceUpdatesStandalone#testDVUpdatesWithDelete to 
check that in-place update for non existed docs will result in a doc creation, 
I think it's ok to have it's distributed analog. 

 

> AddUpdateCommand#prevVersion is not cleared which may lead to problem for 
> in-place updates of non existed documents
> ---
>
> Key: SOLR-11459
> URL: https://issues.apache.org/jira/browse/SOLR-11459
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
>
> I have a 1_shard / *m*_replicas SolrCloud cluster with Solr 6.6.0 and run 
> batches of 5 - 10k in-place updates from time to time. 
> Once I noticed that job "hangs" - it started and couldn't finish for a a 
> while.
> Logs were full of messages like:
> {code} Missing update, on which current in-place update depends on, hasn't 
> arrived. id=__, looking for version=___, last found version=0"  {code}
> {code} 
> Tried to fetch document ___ from the leader, but the leader says document has 
> been deleted. Deleting the document here and skipping this update: Last found 
> version: 0, was looking for: ___",24,0,"but the leader says document has been 
> deleted. Deleting the document here and skipping this update: Last found 
> version: 0
> {code}
> Further analysis shows that:
> * There are 100-500 updates for non-existed documents among other updates 
> (something that I have to deal with)
> * Leader receives bunch of updates and executes this updates one by one. 
> {{JavabinLoader}} which is used by processing documents reuses same instance 
> of {{AddUpdateCommand}} for every update and just [clearing its state at the 
> end|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99].
>  Field [AddUpdateCommand#prevVersion| 
> https://github.com/apache/lucene-solr/blob/6396cb759f8c799f381b0730636fa412761030ce/solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java#L76]
>  is not cleared.   
> * In case of update is in-place update, but specified document does not 
> exist, this update is processed as a regular atomic update (i.e. new doc is 
> created), but {{prevVersion}} is used as a {{distrib.inplace.prevversion}} 
> parameter in sequential calls to every slave in DistributedUpdateProcessor. 
> {{prevVersion}} wasn't cleared, so it may contain version from previous 
> processed update.
> * Slaves checks it's own version of documents which is 0 (cause doc does not 
> exist), slave thinks that some updates were missed and spends 5 seconds in 
> [DistributedUpdateProcessor#waitForDependentUpdates|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99]
>  waiting for missed updates (no luck) and also tries to get "correct" version 
> from leader (no luck as well) 
> * So update for non existed document costs *m* * 5 sec each
> I workarounded this by explicit check of doc existence, but it probably 
> should be fixed.
> Obviously first guess is that  prevVersion should be cleared in 
> {{AddUpdateCommand#clear}}, but have no clue how to test it.
> {code}
> +++ solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java   
> (revision )
> @@ -78,6 +78,7 @@
>   updateTerm = null;
>   isLastDocInBatch = false;
>   version = 0;
> + prevVersion = -1;
> }
> {code}



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

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

[jira] [Commented] (SOLR-11459) AddUpdateCommand#prevVersion is not cleared which may lead to problem for in-place updates of non existed documents

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-11459:
---

GitHub user werder06 opened a pull request:

https://github.com/apache/lucene-solr/pull/307

SOLR-11459 Clear AddUpdateCommand#prevVersion to fix in-place updates…

… for non existed documents

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/werder06/lucene-solr master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/307.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #307


commit 38a689190e80860e9efcfc6bc121f86656801044
Author: Andrey 
Date:   2018-01-17T02:17:54Z

SOLR-11459 Clear AddUpdateCommand#prevVersion to fix in-place updates for 
non existed documents




> AddUpdateCommand#prevVersion is not cleared which may lead to problem for 
> in-place updates of non existed documents
> ---
>
> Key: SOLR-11459
> URL: https://issues.apache.org/jira/browse/SOLR-11459
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
>
> I have a 1_shard / *m*_replicas SolrCloud cluster with Solr 6.6.0 and run 
> batches of 5 - 10k in-place updates from time to time. 
> Once I noticed that job "hangs" - it started and couldn't finish for a a 
> while.
> Logs were full of messages like:
> {code} Missing update, on which current in-place update depends on, hasn't 
> arrived. id=__, looking for version=___, last found version=0"  {code}
> {code} 
> Tried to fetch document ___ from the leader, but the leader says document has 
> been deleted. Deleting the document here and skipping this update: Last found 
> version: 0, was looking for: ___",24,0,"but the leader says document has been 
> deleted. Deleting the document here and skipping this update: Last found 
> version: 0
> {code}
> Further analysis shows that:
> * There are 100-500 updates for non-existed documents among other updates 
> (something that I have to deal with)
> * Leader receives bunch of updates and executes this updates one by one. 
> {{JavabinLoader}} which is used by processing documents reuses same instance 
> of {{AddUpdateCommand}} for every update and just [clearing its state at the 
> end|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99].
>  Field [AddUpdateCommand#prevVersion| 
> https://github.com/apache/lucene-solr/blob/6396cb759f8c799f381b0730636fa412761030ce/solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java#L76]
>  is not cleared.   
> * In case of update is in-place update, but specified document does not 
> exist, this update is processed as a regular atomic update (i.e. new doc is 
> created), but {{prevVersion}} is used as a {{distrib.inplace.prevversion}} 
> parameter in sequential calls to every slave in DistributedUpdateProcessor. 
> {{prevVersion}} wasn't cleared, so it may contain version from previous 
> processed update.
> * Slaves checks it's own version of documents which is 0 (cause doc does not 
> exist), slave thinks that some updates were missed and spends 5 seconds in 
> [DistributedUpdateProcessor#waitForDependentUpdates|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99]
>  waiting for missed updates (no luck) and also tries to get "correct" version 
> from leader (no luck as well) 
> * So update for non existed document costs *m* * 5 sec each
> I workarounded this by explicit check of doc existence, but it probably 
> should be fixed.
> Obviously first guess is that  prevVersion should be cleared in 
> {{AddUpdateCommand#clear}}, but have no clue how to test it.
> {code}
> +++ solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java   
> (revision )
> @@ -78,6 +78,7 @@
>   updateTerm = null;
>   isLastDocInBatch = false;
>   version = 0;
> + prevVersion = -1;
> }
> {code}



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

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

[GitHub] lucene-solr pull request #307: SOLR-11459 Clear AddUpdateCommand#prevVersion...

[werder06]

GitHub user werder06 opened a pull request:

https://github.com/apache/lucene-solr/pull/307

SOLR-11459 Clear AddUpdateCommand#prevVersion to fix in-place updates…

… for non existed documents

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/werder06/lucene-solr master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/307.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #307


commit 38a689190e80860e9efcfc6bc121f86656801044
Author: Andrey 
Date:   2018-01-17T02:17:54Z

SOLR-11459 Clear AddUpdateCommand#prevVersion to fix in-place updates for 
non existed documents




---

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

[jira] [Commented] (SOLR-11661) Race condition between core creation thread and recovery request from leader causes inconsistent view of documents

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-11661:
-

Attached a patch for reproduce the problem 100%, the case here is 
- when a node get down in DELETECOLLECTION, the correspond cores in that node 
is never being cleanup ( the core.properties, the index dir and tlog dir )
- after that if a core with same name and same collection get created on 
different node, it will reuse the old stale tlog and index dir which leads to 
many problems

> Race condition between core creation thread and recovery request from leader 
> causes inconsistent view of documents
> --
>
> Key: SOLR-11661
> URL: https://issues.apache.org/jira/browse/SOLR-11661
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: 11458-2-MoveReplicaHDFSTest-log.txt, SOLR-11661.patch
>
>
> While testing SOLR-11458, [~ab] ran into an interesting failure which 
> resulted in different document counts between leader and replica. The test is 
> MoveReplicaHDFSTest on jira/solr-11458-2 branch.
> The failure is rare but reproducible on beasting:
> {code}
> reproduce with: ant test  -Dtestcase=MoveReplicaHDFSTest 
> -Dtests.method=testNormalFailedMove -Dtests.seed=161856CB543CD71C 
> -Dtests.slow=true -Dtests.locale=ar-SA -Dtests.timezone=US/Michigan 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 14.2s | MoveReplicaHDFSTest.testNormalFailedMove <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<100> but 
> was:<56>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([161856CB543CD71C:31134983787E4905]:0)
>[junit4]>  at 
> org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:305)
>[junit4]>  at 
> org.apache.solr.cloud.MoveReplicaHDFSTest.testNormalFailedMove(MoveReplicaHDFSTest.java:69)
> {code}



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

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

[jira] [Updated] (SOLR-11661) Race condition between core creation thread and recovery request from leader causes inconsistent view of documents

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-11661:

Attachment: SOLR-11661.patch

> Race condition between core creation thread and recovery request from leader 
> causes inconsistent view of documents
> --
>
> Key: SOLR-11661
> URL: https://issues.apache.org/jira/browse/SOLR-11661
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: 11458-2-MoveReplicaHDFSTest-log.txt, SOLR-11661.patch
>
>
> While testing SOLR-11458, [~ab] ran into an interesting failure which 
> resulted in different document counts between leader and replica. The test is 
> MoveReplicaHDFSTest on jira/solr-11458-2 branch.
> The failure is rare but reproducible on beasting:
> {code}
> reproduce with: ant test  -Dtestcase=MoveReplicaHDFSTest 
> -Dtests.method=testNormalFailedMove -Dtests.seed=161856CB543CD71C 
> -Dtests.slow=true -Dtests.locale=ar-SA -Dtests.timezone=US/Michigan 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 14.2s | MoveReplicaHDFSTest.testNormalFailedMove <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<100> but 
> was:<56>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([161856CB543CD71C:31134983787E4905]:0)
>[junit4]>  at 
> org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:305)
>[junit4]>  at 
> org.apache.solr.cloud.MoveReplicaHDFSTest.testNormalFailedMove(MoveReplicaHDFSTest.java:69)
> {code}



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

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

[jira] [Assigned] (SOLR-11863) Add knnRegress Stream Evaluator to support nearest neighbor regression

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-11863:
-

Assignee: Joel Bernstein

> Add knnRegress Stream Evaluator to support nearest neighbor regression
> --
>
> Key: SOLR-11863
> URL: https://issues.apache.org/jira/browse/SOLR-11863
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: This ticket adds the knnRegress Stream Evaluator to add 
> support for nearest neighbor regression to the Streaming Expressions machine 
> learning library.
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>




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

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

[jira] [Updated] (SOLR-11863) Add knnRegress Stream Evaluator to support nearest neighbor regression

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11863:
--
Fix Version/s: 7.3

> Add knnRegress Stream Evaluator to support nearest neighbor regression
> --
>
> Key: SOLR-11863
> URL: https://issues.apache.org/jira/browse/SOLR-11863
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: This ticket adds the knnRegress Stream Evaluator to add 
> support for nearest neighbor regression to the Streaming Expressions machine 
> learning library.
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>




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

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

[jira] [Created] (SOLR-11863) Add knnRegress Stream Evaluator to support nearest neighbor regression

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-11863:
-

 Summary: Add knnRegress Stream Evaluator to support nearest 
neighbor regression
 Key: SOLR-11863
 URL: https://issues.apache.org/jira/browse/SOLR-11863
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
 Environment: This ticket adds the knnRegress Stream Evaluator to add 
support for nearest neighbor regression to the Streaming Expressions machine 
learning library.
Reporter: Joel Bernstein






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

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

[jira] [Updated] (SOLR-11862) Add fuzzyKmeans Stream Evaluatory

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11862:
--
Fix Version/s: 7.3

> Add fuzzyKmeans Stream Evaluatory
> -
>
> Key: SOLR-11862
> URL: https://issues.apache.org/jira/browse/SOLR-11862
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> This ticket adds the fuzzy kmeans clustering algorithm to the Streaming 
> Expression machine learning library.
>  
> Implementation provided by Apache Commons Math



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

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

[jira] [Created] (SOLR-11862) Add fuzzyKmeans Stream Evaluatory

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-11862:
-

 Summary: Add fuzzyKmeans Stream Evaluatory
 Key: SOLR-11862
 URL: https://issues.apache.org/jira/browse/SOLR-11862
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


This ticket adds the fuzzy kmeans clustering algorithm to the Streaming 
Expression machine learning library.

 

Implementation provided by Apache Commons Math



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

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

[jira] [Assigned] (SOLR-11862) Add fuzzyKmeans Stream Evaluatory

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-11862:
-

Assignee: Joel Bernstein

> Add fuzzyKmeans Stream Evaluatory
> -
>
> Key: SOLR-11862
> URL: https://issues.apache.org/jira/browse/SOLR-11862
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> This ticket adds the fuzzy kmeans clustering algorithm to the Streaming 
> Expression machine learning library.
>  
> Implementation provided by Apache Commons Math



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

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

[jira] [Resolved] (SOLR-10995) No jetties were stopped in ChaosMonkey

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-10995.
--
Resolution: Fixed

No failures since the commit.

> No jetties were stopped in ChaosMonkey
> --
>
> Key: SOLR-10995
> URL: https://issues.apache.org/jira/browse/SOLR-10995
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: 7.0
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: 1339.txt.zip, 1341.txt, SOLR-10995.patch
>
>
> In the last 10 days I've seen 5 failures of different ChaosMonkey tests 
> (nightly) with the message: "The Monkey ran for over 45 seconds and no 
> jetties were stopped - this is worth investigating!" in master only. This is 
> a new kind of failure, maybe something changed to trigger this.
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1333/
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1334/
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1337/
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1339/
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1341/



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

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

[jira] [Assigned] (SOLR-10784) Streaming Expressions machine learning functions library

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-10784:
-

Assignee: Joel Bernstein

> Streaming Expressions machine learning functions library
> 
>
> Key: SOLR-10784
> URL: https://issues.apache.org/jira/browse/SOLR-10784
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
>
> This is an umbrella ticket for Streaming Expression's machine learning 
> function library. It will be used in much the same way that SOLR-10651 is 
> being used for the statistical function library.
> In the beginning many of the tickets will be based on machine learning 
> functions in *Apache Commons Math*, but other ML and matrix math libraries 
> will also used.



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

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

[JENKINS] Lucene-Solr-7.2-Linux (64bit/jdk1.8.0_144) - Build # 149 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Linux/149/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseParallelGC

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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=7318, name=jetty-launcher-1742-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=7318, name=jetty-launcher-1742-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)
at __randomizedtesting.SeedInfo.seed([742A4E45D83F93A6]:0)




Build Log:
[...truncated 12098 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-7.2-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_742A4E45D83F93A6-001/init-core-data-001
   [junit4]   2> 663669 WARN  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[742A4E45D83F93A6]-worker) [   
 ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=15 numCloses=15
   [junit4]   2> 663669 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[742A4E45D83F93A6]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 663670 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[742A4E45D83F93A6]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 663671 INFO  

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 924 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 28244 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (34.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 30.2 MB in 0.04 sec (817.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 73.0 MB in 0.08 sec (866.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 83.4 MB in 0.10 sec (860.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6231 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6231 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 212 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (175.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-8.0.0-src.tgz...
   [smoker] 52.5 MB in 0.06 sec (917.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.tgz...
   [smoker] 150.3 MB in 0.14 sec (1041.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.zip...
   [smoker] 151.4 MB in 0.14 sec (1054.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-8.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8
   [smoker] *** [WARN] *** Your open file limit is currently 6.  
   [smoker]  It should be set to 65000 to avoid operational disruption. 
   [smoker]  If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS 
to false in your profile or solr.in.sh
   [smoker] *** [WARN] ***  Your Max Processes Limit is currently 10240. 
   [smoker]  It should be set to 65000 to avoid operational disruption. 
   [smoker]  If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS 
to false in your profile or 

[jira] [Commented] (SOLR-8327) SolrDispatchFilter is not caching new state format, which results in live fetch from ZK per request if node does not contain core from collection

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8327:
-

So after this patch we will make one request every 2 seconds to ZK if a query 
comes in for a collection that has no replicas hosted locally?

This seems much better than what we have currently .

We seem to be inventing our own caching even though we can set ZK watches. What 
are the downsides if we actually set a watch on these znodes lazily? Is there a 
practical limitation to the number of watches that we could set? [~dragonsinth] 
/ [~noble.paul] any thoughts on this?

> SolrDispatchFilter is not caching new state format, which results in live 
> fetch from ZK per request if node does not contain core from collection
> -
>
> Key: SOLR-8327
> URL: https://issues.apache.org/jira/browse/SOLR-8327
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Jessica Cheng Mallet
>Assignee: Varun Thacker
>Priority: Major
>  Labels: solrcloud
> Attachments: SOLR-8327.patch
>
>
> While perf testing with non-solrj client (request can be sent to any solr 
> node), we noticed a huge amount of data from Zookeeper in our tcpdump (~1G 
> for 20 second dump). From the thread dump, we noticed this:
> java.lang.Object.wait (Native Method)
> java.lang.Object.wait (Object.java:503)
> org.apache.zookeeper.ClientCnxn.submitRequest (ClientCnxn.java:1309)
> org.apache.zookeeper.ZooKeeper.getData (ZooKeeper.java:1152)
> org.apache.solr.common.cloud.SolrZkClient$7.execute (SolrZkClient.java:345)
> org.apache.solr.common.cloud.SolrZkClient$7.execute (SolrZkClient.java:342)
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation 
> (ZkCmdExecutor.java:61)
> org.apache.solr.common.cloud.SolrZkClient.getData (SolrZkClient.java:342)
> org.apache.solr.common.cloud.ZkStateReader.getCollectionLive 
> (ZkStateReader.java:841)
> org.apache.solr.common.cloud.ZkStateReader$7.get (ZkStateReader.java:515)
> org.apache.solr.common.cloud.ClusterState.getCollectionOrNull 
> (ClusterState.java:175)
> org.apache.solr.common.cloud.ClusterState.getLeader (ClusterState.java:98)
> org.apache.solr.servlet.HttpSolrCall.getCoreByCollection 
> (HttpSolrCall.java:784)
> org.apache.solr.servlet.HttpSolrCall.init (HttpSolrCall.java:272)
> org.apache.solr.servlet.HttpSolrCall.call (HttpSolrCall.java:417)
> org.apache.solr.servlet.SolrDispatchFilter.doFilter 
> (SolrDispatchFilter.java:210)
> org.apache.solr.servlet.SolrDispatchFilter.doFilter 
> (SolrDispatchFilter.java:179)
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter 
> (ServletHandler.java:1652)
> org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:585)
> org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143)
> org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:577)
> org.eclipse.jetty.server.session.SessionHandler.doHandle 
> (SessionHandler.java:223)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle 
> (ContextHandler.java:1127)
> org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:515)
> org.eclipse.jetty.server.session.SessionHandler.doScope 
> (SessionHandler.java:185)
> org.eclipse.jetty.server.handler.ContextHandler.doScope 
> (ContextHandler.java:1061)
> org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle 
> (ContextHandlerCollection.java:215)
> org.eclipse.jetty.server.handler.HandlerCollection.handle 
> (HandlerCollection.java:110)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle 
> (HandlerWrapper.java:97)
> org.eclipse.jetty.server.Server.handle (Server.java:499)
> org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:310)
> org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:257)
> org.eclipse.jetty.io.AbstractConnection$2.run (AbstractConnection.java:540)
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob 
> (QueuedThreadPool.java:635)
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run 
> (QueuedThreadPool.java:555)
> java.lang.Thread.run (Thread.java:745)
> Looks like SolrDispatchFilter doesn't have caching similar to the 
> collectionStateCache in CloudSolrClient, so if the node doesn't know about a 
> collection in the new state format, it just live-fetch it from Zookeeper on 
> every request.



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

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

[JENKINS] Lucene-Solr-7.2-Windows (64bit/jdk1.8.0_144) - Build # 45 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.2-Windows/45/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC

7 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestBlockPostingsFormat_967961CC9371-001\testPostingsFormat.testExact-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestBlockPostingsFormat_967961CC9371-001\testPostingsFormat.testExact-003
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestBlockPostingsFormat_967961CC9371-001\testPostingsFormat.testExact-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestBlockPostingsFormat_967961CC9371-001\testPostingsFormat.testExact-003

at __randomizedtesting.SeedInfo.seed([967961CC9371]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testNoUpdateThread

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\replicator\test\J1\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_E5119AA1D129BA3A-001\replicationClientTest-002\1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\replicator\test\J1\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_E5119AA1D129BA3A-001\replicationClientTest-002\1
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\replicator\test\J1\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_E5119AA1D129BA3A-001\replicationClientTest-002\1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.2-Windows\lucene\build\replicator\test\J1\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_E5119AA1D129BA3A-001\replicationClientTest-002\1

at 
__randomizedtesting.SeedInfo.seed([E5119AA1D129BA3A:800859CCF2A9E3FC]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.replicator.PerSessionDirectoryFactory.cleanupSession(PerSessionDirectoryFactory.java:58)
at 
org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.java:259)
at 
org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.java:401)
at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testNoUpdateThread(IndexAndTaxonomyReplicationClientTest.java:227)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
   

[jira] [Commented] (SOLR-11736) Rename knn Streaming Expression to knnSearch and add new knn Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11736:


Commit 2fdd47a1cb7fbcedad4a015cccfc10b6b2fae338 in lucene-solr's branch 
refs/heads/branch_7x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2fdd47a ]

SOLR-11736: Rename knn Streaming Expression to knnSearch and add new knn Stream 
Evaluator


> Rename knn Streaming Expression to knnSearch and add new knn Stream Evaluator
> -
>
> Key: SOLR-11736
> URL: https://issues.apache.org/jira/browse/SOLR-11736
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-11736.patch
>
>
> The current knn Streaming Expression performs a *more like this* search to 
> find nearest neighbors of a specific document. The ticket will rename the knn 
> Streaming Expression to knnSearch.
> This ticket will also add a new knn Stream Evaluator that performs the 
> k-nearest neighbor algorithm on vectors.



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

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

[jira] [Commented] (SOLR-11807) Remove special handling for maxShardsPerNode=-1

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11807:
--

Running tests against the latest patch before committing it

> Remove special handling for maxShardsPerNode=-1
> ---
>
> Key: SOLR-11807
> URL: https://issues.apache.org/jira/browse/SOLR-11807
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11807.patch, SOLR-11807.patch
>
>
> Today we can never restore the cloud example gettingstarted collection 
> because it sets maxShardsPerNode=-1 . We have special handling for -1 in 
> CreateCollectionCmd but not in RestoreCmd.
> Today RestoreCmd does has this check and it fails to restore the collection
> {code}
> if ((numShards * totalReplicasPerShard) > (availableNodeCount * 
> maxShardsPerNode)) {
>   throw new SolrException(ErrorCode.BAD_REQUEST,
>   String.format(Locale.ROOT, "Solr cloud with available number of 
> nodes:%d is insufficient for"
>   + " restoring a collection with %d shards, total replicas per 
> shard %d and maxShardsPerNode %d."
>   + " Consider increasing maxShardsPerNode value OR number of 
> available nodes.",
>   availableNodeCount, numShards, totalReplicasPerShard, 
> maxShardsPerNode));
> }
> {code}
> Steps to reproduce:
> Steps to reproduce:
> 1. ./bin/solr start -e cloud -noprompt : This creates a 2 node cluster and a 
> gettingstarted collection which 2X2
> 2. Added 4 docs (id=1,2,3,4) with commit=true and openSearcher=true (default)
> 3. Call backup: 
> http://localhost:8983/solr/admin/collections?action=BACKUP=gettingstarted_backup=gettingstarted=/Users/varunthacker/solr-7.1.0
> 4. Call restore:
> http://localhost:8983/solr/admin/collections?action=restore=gettingstarted_backup=restore_gettingstarted=/Users/varunthacker/solr-7.1.0



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

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

[jira] [Updated] (SOLR-11807) Remove special handling for maxShardsPerNode=-1

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11807:
-
Attachment: SOLR-11807.patch

> Remove special handling for maxShardsPerNode=-1
> ---
>
> Key: SOLR-11807
> URL: https://issues.apache.org/jira/browse/SOLR-11807
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11807.patch, SOLR-11807.patch
>
>
> Today we can never restore the cloud example gettingstarted collection 
> because it sets maxShardsPerNode=-1 . We have special handling for -1 in 
> CreateCollectionCmd but not in RestoreCmd.
> Today RestoreCmd does has this check and it fails to restore the collection
> {code}
> if ((numShards * totalReplicasPerShard) > (availableNodeCount * 
> maxShardsPerNode)) {
>   throw new SolrException(ErrorCode.BAD_REQUEST,
>   String.format(Locale.ROOT, "Solr cloud with available number of 
> nodes:%d is insufficient for"
>   + " restoring a collection with %d shards, total replicas per 
> shard %d and maxShardsPerNode %d."
>   + " Consider increasing maxShardsPerNode value OR number of 
> available nodes.",
>   availableNodeCount, numShards, totalReplicasPerShard, 
> maxShardsPerNode));
> }
> {code}
> Steps to reproduce:
> Steps to reproduce:
> 1. ./bin/solr start -e cloud -noprompt : This creates a 2 node cluster and a 
> gettingstarted collection which 2X2
> 2. Added 4 docs (id=1,2,3,4) with commit=true and openSearcher=true (default)
> 3. Call backup: 
> http://localhost:8983/solr/admin/collections?action=BACKUP=gettingstarted_backup=gettingstarted=/Users/varunthacker/solr-7.1.0
> 4. Call restore:
> http://localhost:8983/solr/admin/collections?action=restore=gettingstarted_backup=restore_gettingstarted=/Users/varunthacker/solr-7.1.0



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

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

[jira] [Commented] (SOLR-11736) Rename knn Streaming Expression to knnSearch and add new knn Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11736:


Commit 5e2ef5eb73d23cd98af2ebec5cc14730d19c4ca4 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e2ef5e ]

SOLR-11736: Rename knn Streaming Expression to knnSearch and add new knn Stream 
Evaluator


> Rename knn Streaming Expression to knnSearch and add new knn Stream Evaluator
> -
>
> Key: SOLR-11736
> URL: https://issues.apache.org/jira/browse/SOLR-11736
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-11736.patch
>
>
> The current knn Streaming Expression performs a *more like this* search to 
> find nearest neighbors of a specific document. The ticket will rename the knn 
> Streaming Expression to knnSearch.
> This ticket will also add a new knn Stream Evaluator that performs the 
> k-nearest neighbor algorithm on vectors.



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

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-10-ea+37) - Build # 1189 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1189/
Java: 64bit/jdk-10-ea+37 -XX:-UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 3302 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J0-20180116_232043_39511333810892720466717.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x7fef6dbc0765, pid=21961, tid=22060
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (10.0+37) (build 
10-ea+37)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (10-ea+37, mixed mode, 
tiered, g1 gc, linux-amd64)
   [junit4] # Problematic frame:
   [junit4] # V  [libjvm.so+0xbd0765]  Node::add_req(Node*)+0xb5
   [junit4] #
   [junit4] # No core dump will be written. 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] # 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/J0/hs_err_pid21961.log
   [junit4] Default case invoked for: 
   [junit4]opcode  = 0, "Node"
   [junit4] Default case invoked for: 
   [junit4]opcode  = 0, "Node"
   [junit4] #
   [junit4] # Compiler replay data is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/J0/replay_pid21961.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 31 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
/home/jenkins/tools/java/64bit/jdk-10-ea+37/bin/java -XX:-UseCompressedOops 
-XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/heapdumps -ea 
-esa --illegal-access=deny -Dtests.prefix=tests -Dtests.seed=1415AB54710BF260 
-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=7.3.0 -Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/temp
 -Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene 
-Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/clover/db
 
-Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/tools/junit4/tests.policy
 -Dtests.LUCENE_VERSION=7.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=/home/jenkins/workspace/Lucene-Solr-7.x-Linux 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/J0
 -Djunit4.childvm.id=0 -Djunit4.childvm.count=3 -Dfile.encoding=UTF-8 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dtests.filterstacks=true -Dtests.leaveTemporary=false -classpath 

[jira] [Updated] (SOLR-11807) Remove special handling for maxShardsPerNode=-1

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11807:
-
Summary: Remove special handling for maxShardsPerNode=-1  (was: Restore 
collection should treat maxShardsPerNode=-1 as unlimited like create collection)

> Remove special handling for maxShardsPerNode=-1
> ---
>
> Key: SOLR-11807
> URL: https://issues.apache.org/jira/browse/SOLR-11807
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11807.patch
>
>
> Today we can never restore the cloud example gettingstarted collection 
> because it sets maxShardsPerNode=-1 . We have special handling for -1 in 
> CreateCollectionCmd but not in RestoreCmd.
> Today RestoreCmd does has this check and it fails to restore the collection
> {code}
> if ((numShards * totalReplicasPerShard) > (availableNodeCount * 
> maxShardsPerNode)) {
>   throw new SolrException(ErrorCode.BAD_REQUEST,
>   String.format(Locale.ROOT, "Solr cloud with available number of 
> nodes:%d is insufficient for"
>   + " restoring a collection with %d shards, total replicas per 
> shard %d and maxShardsPerNode %d."
>   + " Consider increasing maxShardsPerNode value OR number of 
> available nodes.",
>   availableNodeCount, numShards, totalReplicasPerShard, 
> maxShardsPerNode));
> }
> {code}
> Steps to reproduce:
> Steps to reproduce:
> 1. ./bin/solr start -e cloud -noprompt : This creates a 2 node cluster and a 
> gettingstarted collection which 2X2
> 2. Added 4 docs (id=1,2,3,4) with commit=true and openSearcher=true (default)
> 3. Call backup: 
> http://localhost:8983/solr/admin/collections?action=BACKUP=gettingstarted_backup=gettingstarted=/Users/varunthacker/solr-7.1.0
> 4. Call restore:
> http://localhost:8983/solr/admin/collections?action=restore=gettingstarted_backup=restore_gettingstarted=/Users/varunthacker/solr-7.1.0



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21284/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyQueryFacetCloudTest

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.analytics.legacy.facet.LegacyQueryFacetCloudTest: 1) 
Thread[id=302, name=qtp954657732-302, state=TIMED_WAITING, 
group=TGRP-LegacyQueryFacetCloudTest] at 
java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2192)
 at 
app//org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308)
 at 
app//org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:373)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
 at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)2) 
Thread[id=306, name=qtp954657732-306, state=TIMED_WAITING, 
group=TGRP-LegacyQueryFacetCloudTest] at 
java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2192)
 at 
app//org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308)
 at 
app//org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:373)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
 at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.analytics.legacy.facet.LegacyQueryFacetCloudTest: 
   1) Thread[id=302, name=qtp954657732-302, state=TIMED_WAITING, 
group=TGRP-LegacyQueryFacetCloudTest]
at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@9.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
at 
java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2192)
at 
app//org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308)
at 
app//org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:373)
at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)
   2) Thread[id=306, name=qtp954657732-306, state=TIMED_WAITING, 
group=TGRP-LegacyQueryFacetCloudTest]
at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@9.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
at 
java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2192)
at 
app//org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308)
at 
app//org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:373)
at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.base@9.0.1/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([45803B83EAE37DA6]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyQueryFacetCloudTest

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=302, name=qtp954657732-302, state=TIMED_WAITING, 
group=TGRP-LegacyQueryFacetCloudTest] at 
java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2192)
 at 

Re: Welcome Ignacio Vera as Lucene/Solr committer

[Yonik Seeley]

Congrats Ignacio!

-Yonik


On Thu, Jan 11, 2018 at 11:35 AM, Adrien Grand  wrote:
> Hi all,
>
> Please join me in welcoming Ignacio Vera as the latest Lucene/Solr
> committer.
> Ignacio, it's tradition for you to introduce yourself with a brief bio.
>
> Congratulations and Welcome!

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

[jira] [Updated] (SOLR-11807) Restore collection should treat maxShardsPerNode=-1 as unlimited like create collection

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11807:
-
Attachment: SOLR-11807.patch

> Restore collection should treat maxShardsPerNode=-1 as unlimited like create 
> collection
> ---
>
> Key: SOLR-11807
> URL: https://issues.apache.org/jira/browse/SOLR-11807
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11807.patch
>
>
> Today we can never restore the cloud example gettingstarted collection 
> because it sets maxShardsPerNode=-1 . We have special handling for -1 in 
> CreateCollectionCmd but not in RestoreCmd.
> Today RestoreCmd does has this check and it fails to restore the collection
> {code}
> if ((numShards * totalReplicasPerShard) > (availableNodeCount * 
> maxShardsPerNode)) {
>   throw new SolrException(ErrorCode.BAD_REQUEST,
>   String.format(Locale.ROOT, "Solr cloud with available number of 
> nodes:%d is insufficient for"
>   + " restoring a collection with %d shards, total replicas per 
> shard %d and maxShardsPerNode %d."
>   + " Consider increasing maxShardsPerNode value OR number of 
> available nodes.",
>   availableNodeCount, numShards, totalReplicasPerShard, 
> maxShardsPerNode));
> }
> {code}
> Steps to reproduce:
> Steps to reproduce:
> 1. ./bin/solr start -e cloud -noprompt : This creates a 2 node cluster and a 
> gettingstarted collection which 2X2
> 2. Added 4 docs (id=1,2,3,4) with commit=true and openSearcher=true (default)
> 3. Call backup: 
> http://localhost:8983/solr/admin/collections?action=BACKUP=gettingstarted_backup=gettingstarted=/Users/varunthacker/solr-7.1.0
> 4. Call restore:
> http://localhost:8983/solr/admin/collections?action=restore=gettingstarted_backup=restore_gettingstarted=/Users/varunthacker/solr-7.1.0



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

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

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

[Policeman Jenkins Server]

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

6 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.EchoParamsTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_9E1D8AF009C0F9B2-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_9E1D8AF009C0F9B2-001\init-core-data-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_9E1D8AF009C0F9B2-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_9E1D8AF009C0F9B2-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_9E1D8AF009C0F9B2-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_9E1D8AF009C0F9B2-001\init-core-data-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_9E1D8AF009C0F9B2-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.EchoParamsTest_9E1D8AF009C0F9B2-001

at __randomizedtesting.SeedInfo.seed([9E1D8AF009C0F9B2]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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:  
junit.framework.TestSuite.org.apache.solr.backcompat.TestLuceneIndexBackCompat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.backcompat.TestLuceneIndexBackCompat_9E1D8AF009C0F9B2-001\7.2.1-nocfs-001\7.2.1-nocfs:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.backcompat.TestLuceneIndexBackCompat_9E1D8AF009C0F9B2-001\7.2.1-nocfs-001\7.2.1-nocfs

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.backcompat.TestLuceneIndexBackCompat_9E1D8AF009C0F9B2-001\7.2.1-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.backcompat.TestLuceneIndexBackCompat_9E1D8AF009C0F9B2-001\7.2.1-nocfs-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.backcompat.TestLuceneIndexBackCompat_9E1D8AF009C0F9B2-001\7.2.1-nocfs-001\7.2.1-nocfs:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.backcompat.TestLuceneIndexBackCompat_9E1D8AF009C0F9B2-001\7.2.1-nocfs-001\7.2.1-nocfs
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.backcompat.TestLuceneIndexBackCompat_9E1D8AF009C0F9B2-001\7.2.1-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.backcompat.TestLuceneIndexBackCompat_9E1D8AF009C0F9B2-001\7.2.1-nocfs-001

at __randomizedtesting.SeedInfo.seed([9E1D8AF009C0F9B2]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 

[jira] [Commented] (SOLR-11807) Restore collection should treat maxShardsPerNode=-1 as unlimited like create collection

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11807:
--

I think the better way to solve this problem would be to make sure 
maxShardsPerNode is not set to -1 in the gettingstarted example. Also there is 
no documentation that -1 is a special value of "unlimited" so we should not 
have special handling for that.

> Restore collection should treat maxShardsPerNode=-1 as unlimited like create 
> collection
> ---
>
> Key: SOLR-11807
> URL: https://issues.apache.org/jira/browse/SOLR-11807
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>
> Today we can never restore the cloud example gettingstarted collection 
> because it sets maxShardsPerNode=-1 . We have special handling for -1 in 
> CreateCollectionCmd but not in RestoreCmd.
> Today RestoreCmd does has this check and it fails to restore the collection
> {code}
> if ((numShards * totalReplicasPerShard) > (availableNodeCount * 
> maxShardsPerNode)) {
>   throw new SolrException(ErrorCode.BAD_REQUEST,
>   String.format(Locale.ROOT, "Solr cloud with available number of 
> nodes:%d is insufficient for"
>   + " restoring a collection with %d shards, total replicas per 
> shard %d and maxShardsPerNode %d."
>   + " Consider increasing maxShardsPerNode value OR number of 
> available nodes.",
>   availableNodeCount, numShards, totalReplicasPerShard, 
> maxShardsPerNode));
> }
> {code}
> Steps to reproduce:
> Steps to reproduce:
> 1. ./bin/solr start -e cloud -noprompt : This creates a 2 node cluster and a 
> gettingstarted collection which 2X2
> 2. Added 4 docs (id=1,2,3,4) with commit=true and openSearcher=true (default)
> 3. Call backup: 
> http://localhost:8983/solr/admin/collections?action=BACKUP=gettingstarted_backup=gettingstarted=/Users/varunthacker/solr-7.1.0
> 4. Call restore:
> http://localhost:8983/solr/admin/collections?action=restore=gettingstarted_backup=restore_gettingstarted=/Users/varunthacker/solr-7.1.0



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

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 317 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/317/

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testReadApi

Error Message:
expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([75C131060C852E87:22E8CAB3D777CC9C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testReadApi(AutoScalingHandlerTest.java:725)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)




Build Log:
[...truncated 12659 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest
   [junit4]   2> Creating dataDir: 

[jira] [Updated] (SOLR-11712) Streaming throws IndexOutOfBoundsException against an alias when a shard is down

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11712:

Attachment: SOLR-11712.patch

> Streaming throws IndexOutOfBoundsException against an alias when a shard is 
> down
> 
>
> Key: SOLR-11712
> URL: https://issues.apache.org/jira/browse/SOLR-11712
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11712-with-fix.patch, SOLR-11712-without-fix.patch, 
> SOLR-11712.patch, SOLR-11712.patch, SOLR-11712.patch
>
>
> I have an alias against multiple collections. If any one of the shards the 
> underlying collection is down then the stream handler throws an 
> IndexOutOfBoundsException
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"java.lang.IndexOutOfBoundsException: 
> Index: 0, Size: 0","EOF":true,"RESPONSE_TIME":11}]}}
> {code}
> From the Solr logs:
> {code}
> 2017-12-01 01:42:07.573 ERROR (qtp736709391-29) [c:collection s:shard1 
> r:core_node13 x:collection_shard1_replica1] o.a.s.c.s.i.s.ExceptionStream 
> java.io.IOException: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.constructStreams(CloudSolrStream.java:414)
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:305)
> at 
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:51)
> at 
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:535)
> at 
> org.apache.solr.client.solrj.io.stream.TupleStream.writeMap(TupleStream.java:83)
> at 
> org.apache.solr.response.JSONWriter.writeMap(JSONResponseWriter.java:547)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:193)
> at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
> at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
> at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
> at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:809)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:538)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at 
> 

[jira] [Updated] (SOLR-11712) Streaming throws IndexOutOfBoundsException against an alias when a shard is down

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11712:

Attachment: (was: SOLR-11712.patch)

> Streaming throws IndexOutOfBoundsException against an alias when a shard is 
> down
> 
>
> Key: SOLR-11712
> URL: https://issues.apache.org/jira/browse/SOLR-11712
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11712-with-fix.patch, SOLR-11712-without-fix.patch, 
> SOLR-11712.patch, SOLR-11712.patch, SOLR-11712.patch
>
>
> I have an alias against multiple collections. If any one of the shards the 
> underlying collection is down then the stream handler throws an 
> IndexOutOfBoundsException
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"java.lang.IndexOutOfBoundsException: 
> Index: 0, Size: 0","EOF":true,"RESPONSE_TIME":11}]}}
> {code}
> From the Solr logs:
> {code}
> 2017-12-01 01:42:07.573 ERROR (qtp736709391-29) [c:collection s:shard1 
> r:core_node13 x:collection_shard1_replica1] o.a.s.c.s.i.s.ExceptionStream 
> java.io.IOException: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.constructStreams(CloudSolrStream.java:414)
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:305)
> at 
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:51)
> at 
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:535)
> at 
> org.apache.solr.client.solrj.io.stream.TupleStream.writeMap(TupleStream.java:83)
> at 
> org.apache.solr.response.JSONWriter.writeMap(JSONResponseWriter.java:547)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:193)
> at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
> at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
> at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
> at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:809)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:538)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at 
> 

[jira] [Updated] (SOLR-11712) Streaming throws IndexOutOfBoundsException against an alias when a shard is down

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11712:

Attachment: SOLR-11712.patch

> Streaming throws IndexOutOfBoundsException against an alias when a shard is 
> down
> 
>
> Key: SOLR-11712
> URL: https://issues.apache.org/jira/browse/SOLR-11712
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11712-with-fix.patch, SOLR-11712-without-fix.patch, 
> SOLR-11712.patch, SOLR-11712.patch, SOLR-11712.patch
>
>
> I have an alias against multiple collections. If any one of the shards the 
> underlying collection is down then the stream handler throws an 
> IndexOutOfBoundsException
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"java.lang.IndexOutOfBoundsException: 
> Index: 0, Size: 0","EOF":true,"RESPONSE_TIME":11}]}}
> {code}
> From the Solr logs:
> {code}
> 2017-12-01 01:42:07.573 ERROR (qtp736709391-29) [c:collection s:shard1 
> r:core_node13 x:collection_shard1_replica1] o.a.s.c.s.i.s.ExceptionStream 
> java.io.IOException: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.constructStreams(CloudSolrStream.java:414)
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:305)
> at 
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:51)
> at 
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:535)
> at 
> org.apache.solr.client.solrj.io.stream.TupleStream.writeMap(TupleStream.java:83)
> at 
> org.apache.solr.response.JSONWriter.writeMap(JSONResponseWriter.java:547)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:193)
> at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
> at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
> at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
> at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:809)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:538)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at 
> 

[jira] [Commented] (SOLR-11712) Streaming throws IndexOutOfBoundsException against an alias when a shard is down

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11712:
-

[~varunthacker],

I should have been clear. Sorry about the confusion. with-fix and without-fix 
are two different tests which are suppose to pass every time.

{{with-fix}}, test class validates, it receives SolrException and the updated 
log error.
{{without-fix}}, test class validates, itr receives IndexOutOfBoundException 
and old error. Since I am catching the error and not throwing again, there is 
no mark of error on logs.
 
{{with-fix}} patch: 176-182

{code}
  try {
getTuples(pstream);
  } catch (Exception e) {
e.printStackTrace();
assertTrue(e.getCause() instanceof SolrException);
assertTrue(e.getMessage().contains("No active nodes for shard:"));
  }
{code}

{{without-fix}} patch: 181-187

{code}
  try {
getTuples(pstream);
  } catch (Exception e) {
assertFalse(e.getCause() instanceof SolrException); // TODO - important 
assertions
assertFalse(e.getMessage().contains("No active nodes for shard:"));
assertTrue(e.getCause() instanceof IndexOutOfBoundsException);
  }
{code}

also, this tests executed for round about 100 seconds on my system, but if it 
is executing within second on yours. I will upload fresh patch with no nightly.

> Streaming throws IndexOutOfBoundsException against an alias when a shard is 
> down
> 
>
> Key: SOLR-11712
> URL: https://issues.apache.org/jira/browse/SOLR-11712
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11712-with-fix.patch, SOLR-11712-without-fix.patch, 
> SOLR-11712.patch, SOLR-11712.patch
>
>
> I have an alias against multiple collections. If any one of the shards the 
> underlying collection is down then the stream handler throws an 
> IndexOutOfBoundsException
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"java.lang.IndexOutOfBoundsException: 
> Index: 0, Size: 0","EOF":true,"RESPONSE_TIME":11}]}}
> {code}
> From the Solr logs:
> {code}
> 2017-12-01 01:42:07.573 ERROR (qtp736709391-29) [c:collection s:shard1 
> r:core_node13 x:collection_shard1_replica1] o.a.s.c.s.i.s.ExceptionStream 
> java.io.IOException: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.constructStreams(CloudSolrStream.java:414)
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:305)
> at 
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:51)
> at 
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:535)
> at 
> org.apache.solr.client.solrj.io.stream.TupleStream.writeMap(TupleStream.java:83)
> at 
> org.apache.solr.response.JSONWriter.writeMap(JSONResponseWriter.java:547)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:193)
> at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
> at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
> at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
> at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:809)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:538)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at 
> 

[jira] [Created] (SOLR-11861) ConfigSets CREATE baseConfigSet param should default to _default

[David Smiley (JIRA)]

David Smiley created SOLR-11861:
---

 Summary: ConfigSets CREATE baseConfigSet param should default to 
_default
 Key: SOLR-11861
 URL: https://issues.apache.org/jira/browse/SOLR-11861
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Reporter: David Smiley


It would be nice if I didn't have to specify the baseConfigSet param now that 
we have a default configSet "_default".



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

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

[jira] [Commented] (SOLR-11832) Restore from backup creates old format collections

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11832:
--

Thanks Tim! I hope back-porting  SOLR-11860  fixes your problem

> Restore from backup creates old format collections
> --
>
> Key: SOLR-11832
> URL: https://issues.apache.org/jira/browse/SOLR-11832
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.2, 6.6.2
>Reporter: Tim Owen
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11832.patch
>
>
> Restoring a collection from a backup always creates the new collection using 
> the old format state json (format 1), as a global clusterstate.json file at 
> top level of ZK. All new collections should be defaulting to use the newer 
> per-collection (format 2) in /collections/.../state.json
> As we're running clusters with many collections, the old global state format 
> isn't good for us, so as a workaround for now we're calling 
> MIGRATESTATEFORMAT immediately after the RESTORE call.
> This bug was mentioned in the comments of SOLR-5750 and also recently 
> mentioned by [~varunthacker] in SOLR-11560
> Code patch attached, but as per [~dsmiley]'s comment in the code, fixing this 
> means at least 1 test class doesn't succeed anymore. From what I can tell, 
> the BasicDistributedZk2Test fails because it's not using the official 
> collection API to create a collection, it seems to be bypassing that and 
> manually creating cores using the core admin api instead, which I think is 
> not enough to ensure the correct ZK nodes are created. The test superclass 
> has some methods to create a collection which do use the collection api so I 
> could try fixing the tests (I'm just not that familiar with why those 
> BasicDistributed*Test classes aren't using the collection api).



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

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

[jira] [Resolved] (SOLR-11832) Restore from backup creates old format collections

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-11832.
--
Resolution: Duplicate

Let's address changing the default behaviour on SOLR-11860

> Restore from backup creates old format collections
> --
>
> Key: SOLR-11832
> URL: https://issues.apache.org/jira/browse/SOLR-11832
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.2, 6.6.2
>Reporter: Tim Owen
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11832.patch
>
>
> Restoring a collection from a backup always creates the new collection using 
> the old format state json (format 1), as a global clusterstate.json file at 
> top level of ZK. All new collections should be defaulting to use the newer 
> per-collection (format 2) in /collections/.../state.json
> As we're running clusters with many collections, the old global state format 
> isn't good for us, so as a workaround for now we're calling 
> MIGRATESTATEFORMAT immediately after the RESTORE call.
> This bug was mentioned in the comments of SOLR-5750 and also recently 
> mentioned by [~varunthacker] in SOLR-11560
> Code patch attached, but as per [~dsmiley]'s comment in the code, fixing this 
> means at least 1 test class doesn't succeed anymore. From what I can tell, 
> the BasicDistributedZk2Test fails because it's not using the official 
> collection API to create a collection, it seems to be bypassing that and 
> manually creating cores using the core admin api instead, which I think is 
> not enough to ensure the correct ZK nodes are created. The test superclass 
> has some methods to create a collection which do use the collection api so I 
> could try fixing the tests (I'm just not that familiar with why those 
> BasicDistributed*Test classes aren't using the collection api).



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

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

[jira] [Commented] (SOLR-11586) Restored collection uses stateFormat=1 instead of 2

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11586:
--

[~noble.paul] I've created SOLR-11860 to address that

> Restored collection uses stateFormat=1 instead of 2
> ---
>
> Key: SOLR-11586
> URL: https://issues.apache.org/jira/browse/SOLR-11586
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11586.patch
>
>
> In SOLR-11560 I noticed that the restored collection is using stateFormat=1 . 
> It should be creating the collection with stateFormat=2 which would mean the 
> collection should be residing under 
> {{"/collections/collection_name/state.json}}



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

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

[jira] [Created] (SOLR-11860) Change the default state format to 2

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-11860:


 Summary: Change the default state format to 2
 Key: SOLR-11860
 URL: https://issues.apache.org/jira/browse/SOLR-11860
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
 Environment: Today the add collection command explicitly set's the 
collection state to version 2 if not explicitly specified. The default behavior 
is still stateFormat=1

 

Because of this we found bugs like SOLR-11586 . 

 

Solr should change the default state format instead of individual APIs having 
to explicitly set is . The patch provided by Tim Owen on SOLR-11832 would be 
applicable here
Reporter: Varun Thacker






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

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

[jira] [Updated] (SOLR-11860) Change the default state format to 2

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11860:
-
Description: 
Today the add collection command explicitly set's the collection state to 
version 2 if not explicitly specified. The default behavior is still 
stateFormat=1

 

Because of this we found bugs like SOLR-11586 . 

 

Solr should change the default state format instead of individual APIs having 
to explicitly set is . The patch provided by Tim Owen on SOLR-11832 would be 
applicable here

> Change the default state format to 2
> 
>
> Key: SOLR-11860
> URL: https://issues.apache.org/jira/browse/SOLR-11860
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: Today the add collection command explicitly set's the 
> collection state to version 2 if not explicitly specified. The default 
> behavior is still stateFormat=1
>  
> Because of this we found bugs like SOLR-11586 . 
>  
> Solr should change the default state format instead of individual APIs having 
> to explicitly set is . The patch provided by Tim Owen on SOLR-11832 would be 
> applicable here
>Reporter: Varun Thacker
>Priority: Major
>
> Today the add collection command explicitly set's the collection state to 
> version 2 if not explicitly specified. The default behavior is still 
> stateFormat=1
>  
> Because of this we found bugs like SOLR-11586 . 
>  
> Solr should change the default state format instead of individual APIs having 
> to explicitly set is . The patch provided by Tim Owen on SOLR-11832 would be 
> applicable here



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

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

[jira] [Updated] (SOLR-11860) Change the default state format to 2

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11860:
-
Environment: (was: Today the add collection command explicitly set's 
the collection state to version 2 if not explicitly specified. The default 
behavior is still stateFormat=1

 

Because of this we found bugs like SOLR-11586 . 

 

Solr should change the default state format instead of individual APIs having 
to explicitly set is . The patch provided by Tim Owen on SOLR-11832 would be 
applicable here)

> Change the default state format to 2
> 
>
> Key: SOLR-11860
> URL: https://issues.apache.org/jira/browse/SOLR-11860
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
>
> Today the add collection command explicitly set's the collection state to 
> version 2 if not explicitly specified. The default behavior is still 
> stateFormat=1
>  
> Because of this we found bugs like SOLR-11586 . 
>  
> Solr should change the default state format instead of individual APIs having 
> to explicitly set is . The patch provided by Tim Owen on SOLR-11832 would be 
> applicable here



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

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

[jira] [Resolved] (SOLR-11817) Move Collections API classes to it's own package

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-11817.
--
   Resolution: Fixed
Fix Version/s: 7.3
   master (8.0)

> Move Collections API classes to it's own package
> 
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the 
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move 
> the respected classes under that.



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

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

[jira] [Commented] (SOLR-11712) Streaming throws IndexOutOfBoundsException against an alias when a shard is down

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11712:
--

Hi Amrit,

 

Let's backup for a second. I applied SOLR-11712-without-fix.patch against 
master . Then I ran 

StreamingAliasColTest commenting out the nightly annotation. The test passes ( 
which I'm guessing it shouldn't since it's the no fix patch ) . Also I don't 
see any IndexOutOfBoundsException error in the log

 

Also do we really need to annotate it as nightly? The test locally doesn't take 
more than 5-10s to run 

> Streaming throws IndexOutOfBoundsException against an alias when a shard is 
> down
> 
>
> Key: SOLR-11712
> URL: https://issues.apache.org/jira/browse/SOLR-11712
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11712-with-fix.patch, SOLR-11712-without-fix.patch, 
> SOLR-11712.patch, SOLR-11712.patch
>
>
> I have an alias against multiple collections. If any one of the shards the 
> underlying collection is down then the stream handler throws an 
> IndexOutOfBoundsException
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"java.lang.IndexOutOfBoundsException: 
> Index: 0, Size: 0","EOF":true,"RESPONSE_TIME":11}]}}
> {code}
> From the Solr logs:
> {code}
> 2017-12-01 01:42:07.573 ERROR (qtp736709391-29) [c:collection s:shard1 
> r:core_node13 x:collection_shard1_replica1] o.a.s.c.s.i.s.ExceptionStream 
> java.io.IOException: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.constructStreams(CloudSolrStream.java:414)
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:305)
> at 
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:51)
> at 
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:535)
> at 
> org.apache.solr.client.solrj.io.stream.TupleStream.writeMap(TupleStream.java:83)
> at 
> org.apache.solr.response.JSONWriter.writeMap(JSONResponseWriter.java:547)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:193)
> at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
> at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
> at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
> at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:809)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:538)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at 

[jira] [Resolved] (LUCENE-8129) Support for defining a Unicode set filter when using ICUFoldingFilter

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-8129.
-
   Resolution: Fixed
Fix Version/s: 7.3
   trunk

Thanks [~emaijala]!

> Support for defining a Unicode set filter when using ICUFoldingFilter
> -
>
> Key: LUCENE-8129
> URL: https://issues.apache.org/jira/browse/LUCENE-8129
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Ere Maijala
>Priority: Minor
>  Labels: ICUFoldingFilterFactory, patch-available, patch-with-test
> Fix For: trunk, 7.3
>
> Attachments: LUCENE-8129.patch, LUCENE-8129.patch
>
>
> While ICUNormalizer2FilterFactory supports a filter attribute to define a 
> Unicode set filter, ICUFoldingFilterFactory does not support it. A filter 
> allows one to e.g. exclude a set of characters from being folded. E.g. for 
> Finnish and Swedish the filter could be defined like this:
>   
> Note: An additional MappingCharFilterFactory or solr.LowerCaseFilterFactory 
> would be needed for lowercasing the characters excluded from folding. This is 
> similar to what ElasticSearch provides (see 
> https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-icu-folding.html).
> I'll add a patch that does this similar to ICUNormalizer2FilterFactory. 
> Applies at least to master and branch_7x.



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

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

[jira] [Commented] (LUCENE-8129) Support for defining a Unicode set filter when using ICUFoldingFilter

[ASF subversion and git services (JIRA)]

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

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

Commit d3d1b6b96ef24885a8b25e5d08bd47666597dea4 in lucene-solr's branch 
refs/heads/branch_7x from Rob Muir
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d3d1b6b ]

LUCENE-8129: allow passing filtered unicode sets to ICUFoldingFilter


> Support for defining a Unicode set filter when using ICUFoldingFilter
> -
>
> Key: LUCENE-8129
> URL: https://issues.apache.org/jira/browse/LUCENE-8129
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Ere Maijala
>Priority: Minor
>  Labels: ICUFoldingFilterFactory, patch-available, patch-with-test
> Attachments: LUCENE-8129.patch, LUCENE-8129.patch
>
>
> While ICUNormalizer2FilterFactory supports a filter attribute to define a 
> Unicode set filter, ICUFoldingFilterFactory does not support it. A filter 
> allows one to e.g. exclude a set of characters from being folded. E.g. for 
> Finnish and Swedish the filter could be defined like this:
>   
> Note: An additional MappingCharFilterFactory or solr.LowerCaseFilterFactory 
> would be needed for lowercasing the characters excluded from folding. This is 
> similar to what ElasticSearch provides (see 
> https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-icu-folding.html).
> I'll add a patch that does this similar to ICUNormalizer2FilterFactory. 
> Applies at least to master and branch_7x.



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

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

[jira] [Commented] (LUCENE-8129) Support for defining a Unicode set filter when using ICUFoldingFilter

[ASF subversion and git services (JIRA)]

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

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

Commit 6781a0d2d3113e4f423bf717e9c8f781374265ca in lucene-solr's branch 
refs/heads/master from Rob Muir
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6781a0d ]

LUCENE-8129: allow passing filtered unicode sets to ICUFoldingFilter


> Support for defining a Unicode set filter when using ICUFoldingFilter
> -
>
> Key: LUCENE-8129
> URL: https://issues.apache.org/jira/browse/LUCENE-8129
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Ere Maijala
>Priority: Minor
>  Labels: ICUFoldingFilterFactory, patch-available, patch-with-test
> Attachments: LUCENE-8129.patch, LUCENE-8129.patch
>
>
> While ICUNormalizer2FilterFactory supports a filter attribute to define a 
> Unicode set filter, ICUFoldingFilterFactory does not support it. A filter 
> allows one to e.g. exclude a set of characters from being folded. E.g. for 
> Finnish and Swedish the filter could be defined like this:
>   
> Note: An additional MappingCharFilterFactory or solr.LowerCaseFilterFactory 
> would be needed for lowercasing the characters excluded from folding. This is 
> similar to what ElasticSearch provides (see 
> https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-icu-folding.html).
> I'll add a patch that does this similar to ICUNormalizer2FilterFactory. 
> Applies at least to master and branch_7x.



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

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

[jira] [Commented] (SOLR-11817) Move Collections API classes to it's own package

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11817:


Commit 1c6cc20ebb3a5096eff33d2ed8eb102508821d24 in lucene-solr's branch 
refs/heads/branch_7x from [~varun_saxena]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1c6cc20 ]

SOLR-11817: Move Collections API classes to it's own package

(cherry picked from commit a3c4f73)


> Move Collections API classes to it's own package
> 
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the 
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move 
> the respected classes under that.



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

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

[jira] [Commented] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11843:
-

Finally figured out the correct javascript syntax.  Attached a patch that seems 
to fix the problem (and the extra parameter that Erick noticed).

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-11843.patch
>
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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

[jira] [Updated] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-11843:

Attachment: SOLR-11843.patch

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-11843.patch
>
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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

[jira] [Updated] (SOLR-11736) Rename knn Streaming Expression to knnSearch and add new knn Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11736:
--
Attachment: SOLR-11736.patch

> Rename knn Streaming Expression to knnSearch and add new knn Stream Evaluator
> -
>
> Key: SOLR-11736
> URL: https://issues.apache.org/jira/browse/SOLR-11736
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-11736.patch
>
>
> The current knn Streaming Expression performs a *more like this* search to 
> find nearest neighbors of a specific document. The ticket will rename the knn 
> Streaming Expression to knnSearch.
> This ticket will also add a new knn Stream Evaluator that performs the 
> k-nearest neighbor algorithm on vectors.



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

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

[jira] [Resolved] (SOLR-11810) Upgrade Jetty to 9.4.8

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-11810.
---
   Resolution: Fixed
Fix Version/s: 7.3

> Upgrade Jetty to 9.4.8
> --
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-11810.patch, SOLR-11810.patch, SOLR-11810.patch, 
> SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



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

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

[jira] [Commented] (SOLR-11810) Upgrade Jetty to 9.4.8

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11810:


Commit 2dc4f9427e765686265d7080c9b558f281ad72b3 in lucene-solr's branch 
refs/heads/branch_7x from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2dc4f94 ]

SOLR-11810: Upgrade Jetty to 9.4.8

(cherry picked from commit a6b5c5b)


> Upgrade Jetty to 9.4.8
> --
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-11810.patch, SOLR-11810.patch, SOLR-11810.patch, 
> SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



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

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

[jira] [Commented] (SOLR-11810) Upgrade Jetty to 9.4.8

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11810:


Commit a6b5c5bfb0dec510ebd53555dbefd3ea703cdbe6 in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a6b5c5b ]

SOLR-11810: Upgrade Jetty to 9.4.8


> Upgrade Jetty to 9.4.8
> --
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-11810.patch, SOLR-11810.patch, SOLR-11810.patch, 
> SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



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

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

[jira] [Commented] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11843:
-

In case it's not clear -- I don't know very much about javascript!

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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

[jira] [Commented] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11843:
-

I was trying to modify the javascript code.  Currently it has this:

{code:js}
    if (coll.routerField) params.routerField = coll.routerField;
{code}

I tried changing params.routerField to params."router.field" ... but this 
completely broke the web page.  Changing it to params.router.field didn't work 
-- the collection wasn't created.

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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

[jira] [Updated] (SOLR-11810) Upgrade Jetty to 9.4.8

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-11810:
--
Summary: Upgrade Jetty to 9.4.8  (was: Upgrade Jetty to 9.4.x )

> Upgrade Jetty to 9.4.8
> --
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-11810.patch, SOLR-11810.patch, SOLR-11810.patch, 
> SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



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

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

[jira] [Comment Edited] (SOLR-11817) Move Collections API classes to it's own package

[Chris Lambertus (JIRA)]

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

Chris Lambertus edited comment on SOLR-11817 at 1/16/18 8:03 PM:
-

Commit a3c4f7388c13cfdeb66d83b434b991e5e159d4cc in lucene-solr's branch 
refs/heads/master from [~varunthacker]
 [ [https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a3c4f73] ]

SOLR-11817: Move Collections API classes to it's own package


was (Author: jira-bot):
Commit a3c4f7388c13cfdeb66d83b434b991e5e159d4cc in lucene-solr's branch 
refs/heads/master from [~varun_saxena]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a3c4f73 ]

SOLR-11817: Move Collections API classes to it's own package


> Move Collections API classes to it's own package
> 
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the 
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move 
> the respected classes under that.



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

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

[jira] [Resolved] (SOLR-11854) multiValued PrimitiveFieldType should implicitly sort on min/max based on the asc/desc keyword

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-11854.
-
   Resolution: Fixed
Fix Version/s: 7.3
   master (8.0)

> multiValued PrimitiveFieldType should implicitly sort on min/max based on the 
> asc/desc keyword
> --
>
> Key: SOLR-11854
> URL: https://issues.apache.org/jira/browse/SOLR-11854
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11854.patch, SOLR-11854.patch
>
>
> Back in SOLR-2522, I added new syntax for (numeric) fields such that the 
> {{field(someMultivaluedFieldName,min|max)}} syntax could be used to select 
> either the min or max value of a multivalued (docvalues) field for use in 
> other functions -- or for sorting.
> A little while back, it occured to me that a good "default" behavior for all 
> primative multivalued fields would be:
> * automatically use the "min" value when {{sort=someMultivaluedFieldName 
> asc}} is attempted
> * automatically use the "max" value when {{sort=someMultivaluedFieldName 
> desc}} is attempted
> These defaults seem like they would be a big improvement over the current 
> "throw an error" default behavior -- especially since it naturally reduces 
> down in the trivial case where all docs have at most 1 value anyway -- and 
> would align in practice with how most people I've talked to seem to think 
> "sorting on a multivalued field" should work in theory.   If users don't like 
> these dafaults, they can always use the explicit {{field(foo,min|max)}} 
> syntax instead (ex: if users always want multivalued fields to sort on the 
> 'min' value, regardless of the asc|desc selector)
> I've been experimenting with this off and on for a while, working up a POC 
> patch -- I think it's worth doing (details to follow in comment)



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

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

[jira] [Commented] (SOLR-11854) multiValued PrimitiveFieldType should implicitly sort on min/max based on the asc/desc keyword

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11854:


Commit 3a10282a175d426523124ffda3db6c3646e795a0 in lucene-solr's branch 
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3a10282 ]

SOLR-11854: multivalued primative fields can now be sorted by implicitly 
choosing the min/max value for asc/desc sort orders

(cherry picked from commit e2bba98dfde0420da84eb740282966ee5624b4d1)


> multiValued PrimitiveFieldType should implicitly sort on min/max based on the 
> asc/desc keyword
> --
>
> Key: SOLR-11854
> URL: https://issues.apache.org/jira/browse/SOLR-11854
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-11854.patch, SOLR-11854.patch
>
>
> Back in SOLR-2522, I added new syntax for (numeric) fields such that the 
> {{field(someMultivaluedFieldName,min|max)}} syntax could be used to select 
> either the min or max value of a multivalued (docvalues) field for use in 
> other functions -- or for sorting.
> A little while back, it occured to me that a good "default" behavior for all 
> primative multivalued fields would be:
> * automatically use the "min" value when {{sort=someMultivaluedFieldName 
> asc}} is attempted
> * automatically use the "max" value when {{sort=someMultivaluedFieldName 
> desc}} is attempted
> These defaults seem like they would be a big improvement over the current 
> "throw an error" default behavior -- especially since it naturally reduces 
> down in the trivial case where all docs have at most 1 value anyway -- and 
> would align in practice with how most people I've talked to seem to think 
> "sorting on a multivalued field" should work in theory.   If users don't like 
> these dafaults, they can always use the explicit {{field(foo,min|max)}} 
> syntax instead (ex: if users always want multivalued fields to sort on the 
> 'min' value, regardless of the asc|desc selector)
> I've been experimenting with this off and on for a while, working up a POC 
> patch -- I think it's worth doing (details to follow in comment)



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

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

[jira] [Commented] (SOLR-11859) CloneFieldUpdateProcessorFactory should not add {set=} to content when cloned to multivalued field

[Jaap de Jong (JIRA)]

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

Jaap de Jong commented on SOLR-11859:
-

Hi Hoss, thank you for your comment. I actually didn't think about it this way, 
but I am indeed using PHP Solarium to push the data to SOLR. I'm using a "set" 
modifier there, like this:  

$update = $solrClient->createUpdate();

$document = $update->createDocument();

$document->setField('s_description', $source->description, null, 'set');

//etc.

$update->addDocument($document);

$solrClient->update($update);

 

I'm using the same code when doing partial atomic updates, so my initial insert 
might actually be pushed to solr in "atomic update style" meaning that it would 
need different code on my side. I'll test further with this a.s.a.p. Thank you!

> CloneFieldUpdateProcessorFactory should not add {set=} to content when cloned 
> to multivalued field
> --
>
> Key: SOLR-11859
> URL: https://issues.apache.org/jira/browse/SOLR-11859
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.2
>Reporter: Jaap de Jong
>Priority: Minor
>
> I'm using the CloneFieldUpdateProcessorFactory to copy content from all 
> string fields _except some predefined fields_ to a multivalued "text_final" 
> field. This seems to work, however each value value is prepended with 
> "\{set=" and appended with "}".
> Expected result
>  Just clone all the original values into the multivalued field +without 
> "\{set=}".+  
> In my schema this field is defined as:
> {{ multiValued="true"/>}}
> The fieldType is defined as:
> {{ positionIncrementGap="100">}}
>  {{}}
>  {{ replacement=' ' />}}
> {{}}
>  {{}}
>  {{ words="lang/stopwords_nl.txt"}}
>  {{format="snowball"/>}}
>  {{  {{dictionary="lang/nederlands/nl_NL.dic"}}
>  {{affix="lang/nederlands/nl_NL.aff"}}
>  {{ignoreCase="true"/>}}
>  {{}}
>  {{}}
> In my updateRequestProcessorChain the processor is defined as:
> {{}}
>  {{}}
>  {{s_.*}}
>  {{}}
>  {{s_description}}
>  {{s_image_link}}
>  {{s_link}}
>  {{}}
>  {{}}
>  {{text_final}}
>  {{}}



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

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

[jira] [Commented] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11843:
--

{quote}we should make the labels on the text boxes match the real parameter as 
well as fix what's sent to Solr
{quote}
I assumed that was what Shawn was trying to do, but it seems strange that just 
changing the parameter names would completely mess up the UI.

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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

[jira] [Commented] (SOLR-8327) SolrDispatchFilter is not caching new state format, which results in live fetch from ZK per request if node does not contain core from collection

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8327:


I plan to commit this shortly, unless there are any objections. We can open a 
follow up Jira to tackle the smart caching here, which will be an improvement 
over this.

> SolrDispatchFilter is not caching new state format, which results in live 
> fetch from ZK per request if node does not contain core from collection
> -
>
> Key: SOLR-8327
> URL: https://issues.apache.org/jira/browse/SOLR-8327
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Jessica Cheng Mallet
>Assignee: Varun Thacker
>Priority: Major
>  Labels: solrcloud
> Attachments: SOLR-8327.patch
>
>
> While perf testing with non-solrj client (request can be sent to any solr 
> node), we noticed a huge amount of data from Zookeeper in our tcpdump (~1G 
> for 20 second dump). From the thread dump, we noticed this:
> java.lang.Object.wait (Native Method)
> java.lang.Object.wait (Object.java:503)
> org.apache.zookeeper.ClientCnxn.submitRequest (ClientCnxn.java:1309)
> org.apache.zookeeper.ZooKeeper.getData (ZooKeeper.java:1152)
> org.apache.solr.common.cloud.SolrZkClient$7.execute (SolrZkClient.java:345)
> org.apache.solr.common.cloud.SolrZkClient$7.execute (SolrZkClient.java:342)
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation 
> (ZkCmdExecutor.java:61)
> org.apache.solr.common.cloud.SolrZkClient.getData (SolrZkClient.java:342)
> org.apache.solr.common.cloud.ZkStateReader.getCollectionLive 
> (ZkStateReader.java:841)
> org.apache.solr.common.cloud.ZkStateReader$7.get (ZkStateReader.java:515)
> org.apache.solr.common.cloud.ClusterState.getCollectionOrNull 
> (ClusterState.java:175)
> org.apache.solr.common.cloud.ClusterState.getLeader (ClusterState.java:98)
> org.apache.solr.servlet.HttpSolrCall.getCoreByCollection 
> (HttpSolrCall.java:784)
> org.apache.solr.servlet.HttpSolrCall.init (HttpSolrCall.java:272)
> org.apache.solr.servlet.HttpSolrCall.call (HttpSolrCall.java:417)
> org.apache.solr.servlet.SolrDispatchFilter.doFilter 
> (SolrDispatchFilter.java:210)
> org.apache.solr.servlet.SolrDispatchFilter.doFilter 
> (SolrDispatchFilter.java:179)
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter 
> (ServletHandler.java:1652)
> org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:585)
> org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143)
> org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:577)
> org.eclipse.jetty.server.session.SessionHandler.doHandle 
> (SessionHandler.java:223)
> org.eclipse.jetty.server.handler.ContextHandler.doHandle 
> (ContextHandler.java:1127)
> org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:515)
> org.eclipse.jetty.server.session.SessionHandler.doScope 
> (SessionHandler.java:185)
> org.eclipse.jetty.server.handler.ContextHandler.doScope 
> (ContextHandler.java:1061)
> org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141)
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle 
> (ContextHandlerCollection.java:215)
> org.eclipse.jetty.server.handler.HandlerCollection.handle 
> (HandlerCollection.java:110)
> org.eclipse.jetty.server.handler.HandlerWrapper.handle 
> (HandlerWrapper.java:97)
> org.eclipse.jetty.server.Server.handle (Server.java:499)
> org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:310)
> org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:257)
> org.eclipse.jetty.io.AbstractConnection$2.run (AbstractConnection.java:540)
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob 
> (QueuedThreadPool.java:635)
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run 
> (QueuedThreadPool.java:555)
> java.lang.Thread.run (Thread.java:745)
> Looks like SolrDispatchFilter doesn't have caching similar to the 
> collectionStateCache in CloudSolrClient, so if the node doesn't know about a 
> collection in the new state format, it just live-fetch it from Zookeeper on 
> every request.



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

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

[jira] [Commented] (SOLR-11817) Move Collections API classes to it's own package

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11817:


Commit a3c4f7388c13cfdeb66d83b434b991e5e159d4cc in lucene-solr's branch 
refs/heads/master from [~varun_saxena]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a3c4f73 ]

SOLR-11817: Move Collections API classes to it's own package


> Move Collections API classes to it's own package
> 
>
> Key: SOLR-11817
> URL: https://issues.apache.org/jira/browse/SOLR-11817
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11817.patch, SOLR-11817.patch, SOLR-11817.patch
>
>
> Today all collections api classes and tests are in the 
> {{org.apache.solr.cloud}} package.
> We should create a {{org.apache.solr.cloud.api.collections}} package and move 
> the respected classes under that.



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

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

[jira] [Commented] (SOLR-11854) multiValued PrimitiveFieldType should implicitly sort on min/max based on the asc/desc keyword

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11854:


Commit e2bba98dfde0420da84eb740282966ee5624b4d1 in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e2bba98 ]

SOLR-11854: multivalued primative fields can now be sorted by implicitly 
choosing the min/max value for asc/desc sort orders


> multiValued PrimitiveFieldType should implicitly sort on min/max based on the 
> asc/desc keyword
> --
>
> Key: SOLR-11854
> URL: https://issues.apache.org/jira/browse/SOLR-11854
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-11854.patch, SOLR-11854.patch
>
>
> Back in SOLR-2522, I added new syntax for (numeric) fields such that the 
> {{field(someMultivaluedFieldName,min|max)}} syntax could be used to select 
> either the min or max value of a multivalued (docvalues) field for use in 
> other functions -- or for sorting.
> A little while back, it occured to me that a good "default" behavior for all 
> primative multivalued fields would be:
> * automatically use the "min" value when {{sort=someMultivaluedFieldName 
> asc}} is attempted
> * automatically use the "max" value when {{sort=someMultivaluedFieldName 
> desc}} is attempted
> These defaults seem like they would be a big improvement over the current 
> "throw an error" default behavior -- especially since it naturally reduces 
> down in the trivial case where all docs have at most 1 value anyway -- and 
> would align in practice with how most people I've talked to seem to think 
> "sorting on a multivalued field" should work in theory.   If users don't like 
> these dafaults, they can always use the explicit {{field(foo,min|max)}} 
> syntax instead (ex: if users always want multivalued fields to sort on the 
> 'min' value, regardless of the asc|desc selector)
> I've been experimenting with this off and on for a while, working up a POC 
> patch -- I think it's worth doing (details to follow in comment)



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

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

[jira] [Commented] (SOLR-11810) Upgrade Jetty to 9.4.x

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11810:
---

Same patch without inadvertent .DS_store

> Upgrade Jetty to 9.4.x 
> ---
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-11810.patch, SOLR-11810.patch, SOLR-11810.patch, 
> SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



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

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

[jira] [Updated] (SOLR-11810) Upgrade Jetty to 9.4.x

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-11810:
--
Attachment: SOLR-11810.patch

> Upgrade Jetty to 9.4.x 
> ---
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-11810.patch, SOLR-11810.patch, SOLR-11810.patch, 
> SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



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

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

[jira] [Updated] (SOLR-11810) Upgrade Jetty to 9.4.x

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-11810:
--
Attachment: (was: SOLR-11810.patch)

> Upgrade Jetty to 9.4.x 
> ---
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-11810.patch, SOLR-11810.patch, SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



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

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

[jira] [Updated] (SOLR-11810) Upgrade Jetty to 9.4.x

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-11810:
--
Attachment: SOLR-11810.patch

> Upgrade Jetty to 9.4.x 
> ---
>
> Key: SOLR-11810
> URL: https://issues.apache.org/jira/browse/SOLR-11810
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-11810.patch, SOLR-11810.patch, SOLR-11810.patch, 
> SOLR-11810.patch
>
>
> Jetty 9.4.x was released over a year back : 
> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00097.html .  Solr 
> doesn't use any of the major improvements listed on the announce thread but 
> it's the version that's in active development. 
> We should upgrade to Jetty 9.4.x series from 9.3.x
> The latest version right now is 9.4.8.v20171121 . Upgrading it locally 
> required a few compile time changes only. 
> Under "Default Sessions" in 
> https://www.eclipse.org/jetty/documentation/9.4.x/upgrading-jetty.html#_upgrading_from_jetty_9_3_x_to_jetty_9_4_0
>   it states that "In previous versions of Jetty this was referred to as 
> "hash" session management." . 
> The patch fixes all the compile time issues.
> Currently two tests are failing:
> TestRestManager
> TestManagedSynonymGraphFilterFactory
> Steps to upgrade the Jetty version were :
> 1. Modify {{ivy-versions.properties}} to reflect the new version number
> 2. Run {{ant jar-checksums}} to generate new JAR checksums



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

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

[jira] [Commented] (SOLR-11859) CloneFieldUpdateProcessorFactory should not add {set=} to content when cloned to multivalued field

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-11859:
-

I don't understand this Jira –AFAIK there is nothing in 
CloneFieldUpdateProcessor that will automatically prepend "{set=" to any field 
values – nor is there anything that will try to convert the field values into 
atomic updates (which might be missread as prepended "set" strings?)

 

The Jira description includes an example field/fieldType and processor 
declaration – but no full details on exactly what the requests look, with full 
input/output and details on the entire update chain.  (ie: full solrconfig.xml 
+ full schema showing both the sources nad dest fields + sample curl command to 
index + sample curl command to /get or /query the added documents)

I'm 99% certian something else is going on here unrelated to 
CloneFieldUpdateProcessorFactory

 

> CloneFieldUpdateProcessorFactory should not add {set=} to content when cloned 
> to multivalued field
> --
>
> Key: SOLR-11859
> URL: https://issues.apache.org/jira/browse/SOLR-11859
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.2
>Reporter: Jaap de Jong
>Priority: Minor
>
> I'm using the CloneFieldUpdateProcessorFactory to copy content from all 
> string fields _except some predefined fields_ to a multivalued "text_final" 
> field. This seems to work, however each value value is prepended with 
> "\{set=" and appended with "}".
> Expected result
>  Just clone all the original values into the multivalued field +without 
> "\{set=}".+  
> In my schema this field is defined as:
> {{ multiValued="true"/>}}
> The fieldType is defined as:
> {{ positionIncrementGap="100">}}
>  {{}}
>  {{ replacement=' ' />}}
> {{}}
>  {{}}
>  {{ words="lang/stopwords_nl.txt"}}
>  {{format="snowball"/>}}
>  {{  {{dictionary="lang/nederlands/nl_NL.dic"}}
>  {{affix="lang/nederlands/nl_NL.aff"}}
>  {{ignoreCase="true"/>}}
>  {{}}
>  {{}}
> In my updateRequestProcessorChain the processor is defined as:
> {{}}
>  {{}}
>  {{s_.*}}
>  {{}}
>  {{s_description}}
>  {{s_image_link}}
>  {{s_link}}
>  {{}}
>  {{}}
>  {{text_final}}
>  {{}}



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

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

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 403 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/403/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

5 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionTooManyReplicasTest.testAddTooManyReplicas

Error Message:
Could not find collection : TooManyReplicasInSeveralFlavors

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : 
TooManyReplicasInSeveralFlavors
at 
__randomizedtesting.SeedInfo.seed([36C7233BDC42615E:BB9557E392A45EEF]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:247)
at 
org.apache.solr.cloud.CollectionTooManyReplicasTest.getAllNodeNames(CollectionTooManyReplicasTest.java:217)
at 
org.apache.solr.cloud.CollectionTooManyReplicasTest.testAddTooManyReplicas(CollectionTooManyReplicasTest.java:62)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (SOLR-11859) CloneFieldUpdateProcessorFactory should not add {set=} to content when cloned to multivalued field

[Jaap de Jong (JIRA)]

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

Jaap de Jong commented on SOLR-11859:
-

hi Erick, Unfortunately this doesn't work for me as I cannot exclude specific 
fields when using copyField; 



would also copy s_description, s_image_link and s_link which I don't want to 
show up in "text_final".

> CloneFieldUpdateProcessorFactory should not add {set=} to content when cloned 
> to multivalued field
> --
>
> Key: SOLR-11859
> URL: https://issues.apache.org/jira/browse/SOLR-11859
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.2
>Reporter: Jaap de Jong
>Priority: Minor
>
> I'm using the CloneFieldUpdateProcessorFactory to copy content from all 
> string fields _except some predefined fields_ to a multivalued "text_final" 
> field. This seems to work, however each value value is prepended with 
> "\{set=" and appended with "}".
> Expected result
>  Just clone all the original values into the multivalued field +without 
> "\{set=}".+  
> In my schema this field is defined as:
> {{ multiValued="true"/>}}
> The fieldType is defined as:
> {{ positionIncrementGap="100">}}
>  {{}}
>  {{ replacement=' ' />}}
> {{}}
>  {{}}
>  {{ words="lang/stopwords_nl.txt"}}
>  {{format="snowball"/>}}
>  {{  {{dictionary="lang/nederlands/nl_NL.dic"}}
>  {{affix="lang/nederlands/nl_NL.aff"}}
>  {{ignoreCase="true"/>}}
>  {{}}
>  {{}}
> In my updateRequestProcessorChain the processor is defined as:
> {{}}
>  {{}}
>  {{s_.*}}
>  {{}}
>  {{s_description}}
>  {{s_image_link}}
>  {{s_link}}
>  {{}}
>  {{}}
>  {{text_final}}
>  {{}}



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

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

[jira] [Commented] (SOLR-10308) Solr fails to work with Guava 21.0

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan commented on SOLR-10308:
-

Unfortunately, the patch affects the following hdfs test cases.
{noformat}
   [junit4] HEARTBEAT J1 PID(26866@...): 2018-01-16T19:27:40, stalled for 7988s 
at: HdfsNNFailoverTest (suite)
   [junit4] HEARTBEAT J2 PID(26860@...): 2018-01-16T19:27:40, stalled for 8591s 
at: StressHdfsTest (suite)
   [junit4] HEARTBEAT J0 PID(26869@...): 2018-01-16T19:28:04, stalled for 7141s 
at: MoveReplicaHDFSFailoverTest (suite)
   [junit4] HEARTBEAT J3 PID(26880@...): 2018-01-16T19:28:04, stalled for 8352s 
at: CheckHdfsIndexTest (suite)
   [junit4] HEARTBEAT J1 PID(26866@...): 2018-01-16T19:28:40, stalled for 8048s 
at: HdfsNNFailoverTest (suite)
   [junit4] HEARTBEAT J2 PID(26860@...): 2018-01-16T19:28:40, stalled for 8651s 
at: StressHdfsTest (suite)
   [junit4] HEARTBEAT J0 PID(26869@...): 2018-01-16T19:29:04, stalled for 7201s 
at: MoveReplicaHDFSFailoverTest (suite)
   [junit4] HEARTBEAT J3 PID(26880@...): 2018-01-16T19:29:04, stalled for 8412s 
at: CheckHdfsIndexTest (suite)
{noformat}

> Solr fails to work with Guava 21.0
> --
>
> Key: SOLR-10308
> URL: https://issues.apache.org/jira/browse/SOLR-10308
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.4.2
>Reporter: Vincent Massol
>Priority: Major
>
> This is what we get:
> {noformat}
> Caused by: java.lang.NoSuchMethodError: 
> com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
>   at 
> org.apache.solr.handler.component.HighlightComponent.prepare(HighlightComponent.java:118)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:269)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2299)
>   at 
> org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:178)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
>   at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
>   at 
> org.xwiki.search.solr.internal.AbstractSolrInstance.query(AbstractSolrInstance.java:117)
>   at 
> org.xwiki.query.solr.internal.SolrQueryExecutor.execute(SolrQueryExecutor.java:122)
>   at 
> org.xwiki.query.internal.DefaultQueryExecutorManager.execute(DefaultQueryExecutorManager.java:72)
>   at 
> org.xwiki.query.internal.SecureQueryExecutorManager.execute(SecureQueryExecutorManager.java:67)
>   at org.xwiki.query.internal.DefaultQuery.execute(DefaultQuery.java:287)
>   at org.xwiki.query.internal.ScriptQuery.execute(ScriptQuery.java:237)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395)
>   at 
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384)
>   at 
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173)
>   ... 183 more
> {noformat}
> Guava 21 has removed some signature that solr is currently using.



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

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

[jira] [Commented] (SOLR-11696) /query page generates http link that loads incorrectly-encoded url

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11696:
---

I'm pretty sure JIRA's can't be assigned to a non committer.

But that doesn't matter, you've effectively assigned it to yourself to by 
volunteering...

To work on it, just dive in and make it work. This page has a bunch of tips on 
how to get the code, compile, set up an IDE and the like:

[https://wiki.apache.org/solr/HowToContribute]

It'll take a bit of hunting to track down where this should be done, and 
unfortunately I don't have much knowledge of how the admin UI is put together. 
I do know it's in Angular JS, so look for a lot of *.js files.

 

> /query page generates http link that loads incorrectly-encoded url
> --
>
> Key: SOLR-11696
> URL: https://issues.apache.org/jira/browse/SOLR-11696
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: website
>Reporter: stuart robinson
>Priority: Major
>  Labels: easyfix, newbie, website
>
> i'm trying to query documents that contain both "Covers for Modular Outdoor 
> Club Chairs" and "Resort Club & Ottoman Set" in my "vv" array field.
> that single ampersand seems to breaking the default url encoding that is 
> generated in my browser (Chrome 62.0.3202.94) when i click the search link 
> generated at the top of the /query page of the solr UI.
> in the UI, my q is
> {code}
> vv:"Covers for Modular Outdoor Club Chairs" && vv:"Resort Club & Ottoman Set"
> {code}
> the UI generates the following url.  when I click it, i get different results 
> from the results in the /query UI
> {code}
> http://localhost:8983/solr/films/select?q=vv:"Covers for Modular Outdoor Club 
> Chairs" && vv:"Resort Club & Ottoman Set"
> {code}
> because the url gets encoded wrong.  Resultant url seen in browser:
> {code}
> http://localhost:8983/solr/films/select?q=vv:%22Covers%20for%20Modular%20Outdoor%20Club%20Chairs%22%20&&%20vv:%22Resort%20Club%20&%20Ottoman%20Set%22
> {code}
> Properly-encoded url that leads to correct results:
> {code}
> http://localhost:8983/solr/films/select?q=vv%3A%22Covers%20for%20Modular%20Outdoor%20Club%20Chairs%22%20%26%26%20vv%3A%22Resort%20Club%20%26%20Ottoman%20Set%22
> {code}
> (encoded using https://www.urlencoder.org/)
> if the Solr UI is to generate a clickable link that appears to be equivalent 
> to the UI's search, then it ought to link to the correct search.
> i'm listing this as a "bug" even though it seems to be more of a "flaw" 
> because it's an issue that breaks the user experience and leads to unexpected 
> results.  



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

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

[jira] [Comment Edited] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-11843 at 1/16/18 5:41 PM:


I took a quick look at this, here's the problem

1> use the admin UI to add a collection

2> click "show advanced"

3> enter "blivet" in the routerField text box

The command in the solr log is below. Note "routerField" rather than 
"router.field" is passed as the parameter name:

replicationFactor=1=compositeId=_default=1=eoe=compositeId=CREATE=1&*routerField*=blivet...

It doesn't matter whether the implicit or compositeId field is used.

Another anomaly is that "routerName" is passed as well as "router.name".

params={replicationFactor=1=2&*routerName=implicit*=default=1=bonkers&*router.name=implicit*=CREATE=1=whatever

In lieu of restructuring the command itself to be consistent by either making 
all parameters camelCase or use the dot.notation, we should make the labels on 
the text boxes match the real parameter as well as fix what's sent to Solr I 
should think. Then just pass the correct parameter...


was (Author: erickerickson):
I took a quick look at this, here's the problem

1> use the admin UI to add a collection

2> click "show advanced"

3> enter "blivet" in the routerField text box

The command in the solr log is below. Note "routerField" rather than 
"router.field" is passed as the parameter name:

replicationFactor=1=compositeId=_default=1=eoe=compositeId=CREATE=1&*routerField*=blivet...

It doesn't matter whether the implicit or compositeId field is used.

Another anomaly is that "routerName" is passed as well as "router.name".

params={replicationFactor=1=2&*routerName=implicit*=_default=1=bonkers&*router.name=implicit*=CREATE=1=whatever=json&_=1516123492669

In lieu of restructuring the command itself to be consistent by either making 
all parameters camelCase or use the dot.notation, we should make the labels on 
the text boxes match the real parameter as well as fix what's sent to Solr I 
should think. Then just pass the correct parameter...

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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

[jira] [Commented] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11843:
---

I took a quick look at this, here's the problem

1> use the admin UI to add a collection

2> click "show advanced"

3> enter "blivet" in the routerField text box

The command in the solr log is below. Note "routerField" rather than 
"router.field" is passed as the parameter name:

replicationFactor=1=compositeId=_default=1=eoe=compositeId=CREATE=1&*routerField*=blivet...

It doesn't matter whether the implicit or compositeId field is used.

Another anomaly is that "routerName" is passed as well as "router.name".

params={replicationFactor=1=2&*routerName=implicit*=_default=1=bonkers&*router.name=implicit*=CREATE=1=whatever=json&_=1516123492669

In lieu of restructuring the command itself to be consistent by either making 
all parameters camelCase or use the dot.notation, we should make the labels on 
the text boxes match the real parameter as well as fix what's sent to Solr I 
should think. Then just pass the correct parameter...

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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

[jira] [Commented] (SOLR-11696) /query page generates http link that loads incorrectly-encoded url

[Aditya Srinivasan (JIRA)]

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

Aditya Srinivasan commented on SOLR-11696:
--

I saw the "easy fix" label here and thought I'd work on this. Would the owners 
mind assigning this to me? It would be my first PR/fix and I'd appreciate 
guidance in executing this as well!

> /query page generates http link that loads incorrectly-encoded url
> --
>
> Key: SOLR-11696
> URL: https://issues.apache.org/jira/browse/SOLR-11696
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: website
>Reporter: stuart robinson
>Priority: Major
>  Labels: easyfix, newbie, website
>
> i'm trying to query documents that contain both "Covers for Modular Outdoor 
> Club Chairs" and "Resort Club & Ottoman Set" in my "vv" array field.
> that single ampersand seems to breaking the default url encoding that is 
> generated in my browser (Chrome 62.0.3202.94) when i click the search link 
> generated at the top of the /query page of the solr UI.
> in the UI, my q is
> {code}
> vv:"Covers for Modular Outdoor Club Chairs" && vv:"Resort Club & Ottoman Set"
> {code}
> the UI generates the following url.  when I click it, i get different results 
> from the results in the /query UI
> {code}
> http://localhost:8983/solr/films/select?q=vv:"Covers for Modular Outdoor Club 
> Chairs" && vv:"Resort Club & Ottoman Set"
> {code}
> because the url gets encoded wrong.  Resultant url seen in browser:
> {code}
> http://localhost:8983/solr/films/select?q=vv:%22Covers%20for%20Modular%20Outdoor%20Club%20Chairs%22%20&&%20vv:%22Resort%20Club%20&%20Ottoman%20Set%22
> {code}
> Properly-encoded url that leads to correct results:
> {code}
> http://localhost:8983/solr/films/select?q=vv%3A%22Covers%20for%20Modular%20Outdoor%20Club%20Chairs%22%20%26%26%20vv%3A%22Resort%20Club%20%26%20Ottoman%20Set%22
> {code}
> (encoded using https://www.urlencoder.org/)
> if the Solr UI is to generate a clickable link that appears to be equivalent 
> to the UI's search, then it ought to link to the correct search.
> i'm listing this as a "bug" even though it seems to be more of a "flaw" 
> because it's an issue that breaks the user experience and leads to unexpected 
> results.  



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

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

[jira] [Commented] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11843:
--

Anyway you could share what you tried? Or describe your attempts a little bit?

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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

[jira] [Commented] (SOLR-5642) Query User Interface is Unnecessarily Cryptic

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-5642:


The existing labels are a bit cryptic, but the admin ui is not really meant for 
non developers either. It seems to me that the labels could be more helpful for 
new developers however, and having labels like Query (=) would have a 
somewhat tutorial effect. Mouse over's are not helpful until people know they 
are there, and even then they are painfully slow UI (imho).  a (?) symbol that 
links to docs would also be good, but gets slightly complicated since, as the 
OP notes there are lots of versions, and several locations, and infrastructure 
gets reorganized from time to time potentially breaking such links. I think to 
make it sane, the html docs would need to be packaged and installed locally, 
and served by our jetty.   

> Query User Interface is Unnecessarily Cryptic
> -
>
> Key: SOLR-5642
> URL: https://issues.apache.org/jira/browse/SOLR-5642
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 4.6
>Reporter: Aaron Greenspan
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Solr depends on a lot of parameters to perform queries. These parameters have 
> one- or two-character names like "q" and "fq" and "fl" and "df". It would be 
> extremely easy and extremely helpful to users to use tooltips in the web UI 
> that could explain what these parameters actually mean, and it would be 
> further helpful to link directly to the documentation for each. Right now I 
> have no idea what they mean and since there's several versions of the 
> documentation I'm not even sure how to find the best place to look.
> Also, the word "Dataimport" on the left should be two words: "Data Import" 
> both because "dataimport" is not a word in any language and because the 
> "Schema Browser" appears as two proper words.



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

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 1187 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1187/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC

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

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=22450, name=jetty-launcher-4727-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=22454, name=jetty-launcher-4727-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=22450, name=jetty-launcher-4727-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Commented] (SOLR-11064) Collection APIs should provide disk space hint to Policy when possible

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11064:


Commit ad829c3ea65a0f16884f7e1b8ad8a59c1c9466e8 in lucene-solr's branch 
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ad829c3 ]

SOLR-11064: Collection APIs should use the disk space hint when using policy 
framework


> Collection APIs should provide disk space hint to Policy when possible
> --
>
> Key: SOLR-11064
> URL: https://issues.apache.org/jira/browse/SOLR-11064
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
> SOLR-11063 added disk space hint to Policy. The ADDREPLICA, MOVEREPLICA, 
> SPLITSHARD and REPLACENODE APIs can provide this hint.
> # ADDREPLICA can query the size of the leader's data direcoty for the same 
> shard and pass it to policy
> # MOVEREPLICA again knows the size of the replica being moved
> # SPLITSHARD knows the size of the split indexes before it calls addreplica 
> to create replicas of the sub-shards
> # REPLACENODE can compute the sum of disk usage of all the replicas' data 
> directories
> We should probably include both index and tlog size in the hint to ensure 
> that we have ample space on target nodes.
> We should also take care of HDFS because for movereplica and replacenode, 
> there are no disk space requirements because the original replica's HDFS data 
> and ulog directories are used by the new replicas.



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

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

[jira] [Commented] (SOLR-11064) Collection APIs should provide disk space hint to Policy when possible

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11064:


Commit d99799c75c79b488d4db26c968d4e1a9cf415c6b in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d99799c ]

SOLR-11064: Collection APIs should use the disk space hint when using policy 
framework


> Collection APIs should provide disk space hint to Policy when possible
> --
>
> Key: SOLR-11064
> URL: https://issues.apache.org/jira/browse/SOLR-11064
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
> SOLR-11063 added disk space hint to Policy. The ADDREPLICA, MOVEREPLICA, 
> SPLITSHARD and REPLACENODE APIs can provide this hint.
> # ADDREPLICA can query the size of the leader's data direcoty for the same 
> shard and pass it to policy
> # MOVEREPLICA again knows the size of the replica being moved
> # SPLITSHARD knows the size of the split indexes before it calls addreplica 
> to create replicas of the sub-shards
> # REPLACENODE can compute the sum of disk usage of all the replicas' data 
> directories
> We should probably include both index and tlog size in the hint to ensure 
> that we have ample space on target nodes.
> We should also take care of HDFS because for movereplica and replacenode, 
> there are no disk space requirements because the original replica's HDFS data 
> and ulog directories are used by the new replicas.



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

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

[jira] [Commented] (SOLR-11859) CloneFieldUpdateProcessorFactory should not add {set=} to content when cloned to multivalued field

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11859:
---

In the meantime, would copyField directive(s) in the schema be easier?

> CloneFieldUpdateProcessorFactory should not add {set=} to content when cloned 
> to multivalued field
> --
>
> Key: SOLR-11859
> URL: https://issues.apache.org/jira/browse/SOLR-11859
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.2
>Reporter: Jaap de Jong
>Priority: Minor
>
> I'm using the CloneFieldUpdateProcessorFactory to copy content from all 
> string fields _except some predefined fields_ to a multivalued "text_final" 
> field. This seems to work, however each value value is prepended with 
> "\{set=" and appended with "}".
> Expected result
>  Just clone all the original values into the multivalued field +without 
> "\{set=}".+  
> In my schema this field is defined as:
> {{ multiValued="true"/>}}
> The fieldType is defined as:
> {{ positionIncrementGap="100">}}
>  {{}}
>  {{ replacement=' ' />}}
> {{}}
>  {{}}
>  {{ words="lang/stopwords_nl.txt"}}
>  {{format="snowball"/>}}
>  {{  {{dictionary="lang/nederlands/nl_NL.dic"}}
>  {{affix="lang/nederlands/nl_NL.aff"}}
>  {{ignoreCase="true"/>}}
>  {{}}
>  {{}}
> In my updateRequestProcessorChain the processor is defined as:
> {{}}
>  {{}}
>  {{s_.*}}
>  {{}}
>  {{s_description}}
>  {{s_image_link}}
>  {{s_link}}
>  {{}}
>  {{}}
>  {{text_final}}
>  {{}}



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

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