[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+181) - Build # 20509 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20509/
Java: 64bit/jdk-9-ea+181 -XX:+UseCompressedOops -XX:+UseG1GC 
--illegal-access=deny

All tests passed

Build Log:
[...truncated 13843 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp/junit4-J1-20170921_045307_65916255299946166397499.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps/java_pid1831.hprof 
...
   [junit4] Heap dump file created [337569297 bytes in 0.503 secs]
   [junit4] <<< JVM J1: EOF 

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

Total time: 70 minutes 4 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([B5C266CD0DD00DCF:2F361B2F934A91F3]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:884)
at 
org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:270)
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)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:877)
... 40 more


FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelTerminatingDaemonUpdateStream

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

[Policeman Jenkins Server]

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

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=11709, name=jetty-launcher-2473-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=11708, name=jetty-launcher-2473-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=11709, name=jetty-launcher-2473-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-11323) Expose cache maxSize and autowarm settings in JMX

[Otis Gospodnetic (JIRA)]

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

Otis Gospodnetic commented on SOLR-11323:
-

[~ab] this is that 1-line change we briefly chatted about in Vegas.  It would 
be great if you could this in in the next Solr 7.x minor release. Thanks.

> Expose cache maxSize and autowarm settings in JMX
> -
>
> Key: SOLR-11323
> URL: https://issues.apache.org/jira/browse/SOLR-11323
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: JMX, metrics
>Affects Versions: 7.0, 7.1
>Reporter: Bojan Smid
>
> Before Solr 7.*, cache maxSize and autowarm settings were exposed in JMX 
> along with cache metrics. There was a textual attribute "description" which 
> could be parsed to extract maxSize and autowarm settings. This was very 
> useful for various monitoring tools since maxSize and autowarm could then be 
> displayed on monitoring charts (one could for example compare current size of 
> some cache to its maxSize without digging through configs to find this 
> setting).
> Ideally maxSize and autowarm count/% would be exposed as two separate 
> attributes, but having a single description field (which can be parsed) would 
> also be better than nothing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-7951) New wrapper classes for Geo3d

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-7951.
--
   Resolution: Fixed
Fix Version/s: 7.1

> New wrapper classes for Geo3d
> -
>
> Key: LUCENE-7951
> URL: https://issues.apache.org/jira/browse/LUCENE-7951
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial-extras
>Reporter: Ignacio Vera
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.1
>
> Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, 
> LUCENE-7951.patch, LUCENE-7951.patch, LUCENE-7951.patch
>
>
> Hi,
> After the latest developments in the Geo3d library, in particular:
> [https://issues.apache.org/jira/browse/LUCENE-7906] : Spatial relationships 
> between GeoShapes
> [https://issues.apache.org/jira/browse/LUCENE-7936]: Serialization of 
> GeoShapes.
> I propose a new set of wrapper classes which can be for example linked to 
> Solr as they implement their own SpatialContextFactory. It provides the 
> capability of indexing shapes with 
>  spherical geometry.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d

[ASF subversion and git services (JIRA)]

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

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

Commit 85491401d54c59e1593a5c9f13dca7bfcdda31a2 in lucene-solr's branch 
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8549140 ]

LUCENE-7951: Spatial4j implementations using Geo3d

(cherry picked from commit 035523b)


> New wrapper classes for Geo3d
> -
>
> Key: LUCENE-7951
> URL: https://issues.apache.org/jira/browse/LUCENE-7951
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial-extras
>Reporter: Ignacio Vera
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, 
> LUCENE-7951.patch, LUCENE-7951.patch, LUCENE-7951.patch
>
>
> Hi,
> After the latest developments in the Geo3d library, in particular:
> [https://issues.apache.org/jira/browse/LUCENE-7906] : Spatial relationships 
> between GeoShapes
> [https://issues.apache.org/jira/browse/LUCENE-7936]: Serialization of 
> GeoShapes.
> I propose a new set of wrapper classes which can be for example linked to 
> Solr as they implement their own SpatialContextFactory. It provides the 
> capability of indexing shapes with 
>  spherical geometry.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7951: Spatial4j implementations using Geo3d


> New wrapper classes for Geo3d
> -
>
> Key: LUCENE-7951
> URL: https://issues.apache.org/jira/browse/LUCENE-7951
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial-extras
>Reporter: Ignacio Vera
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, 
> LUCENE-7951.patch, LUCENE-7951.patch, LUCENE-7951.patch
>
>
> Hi,
> After the latest developments in the Geo3d library, in particular:
> [https://issues.apache.org/jira/browse/LUCENE-7906] : Spatial relationships 
> between GeoShapes
> [https://issues.apache.org/jira/browse/LUCENE-7936]: Serialization of 
> GeoShapes.
> I propose a new set of wrapper classes which can be for example linked to 
> Solr as they implement their own SpatialContextFactory. It provides the 
> capability of indexing shapes with 
>  spherical geometry.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+181) - Build # 20508 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20508/
Java: 64bit/jdk-9-ea+181 -XX:+UseCompressedOops -XX:+UseSerialGC 
--illegal-access=deny

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=4990, name=searcherExecutor-2371-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)   
  at 
java.base@9/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
 at 
java.base@9/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base@9/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=4990, name=searcherExecutor-2371-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at java.base@9/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@9/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@9/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
at 
java.base@9/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092)
at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.base@9/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([BC7E72C0B4F00B77]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=4990, name=searcherExecutor-2371-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)   
  at 
java.base@9/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
 at 
java.base@9/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base@9/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=4990, name=searcherExecutor-2371-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at java.base@9/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@9/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@9/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
at 
java.base@9/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092)
at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.base@9/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([BC7E72C0B4F00B77]:0)


FAILED:  org.apache.solr.core.TestLazyCores.testNoCommit

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([BC7E72C0B4F00B77:631ED3117FD768D2]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:884)
at org.apache.solr.core.TestLazyCores.check10(TestLazyCores.java:847)
at 
org.apache.solr.core.TestLazyCores.testNoCommit(TestLazyCores.java:829)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 1) 
Thread[id=13443, name=jetty-launcher-1940-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] 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.security.hadoop.TestImpersonationWithHadoopAuth: 
   1) Thread[id=13443, name=jetty-launcher-1940-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth]
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([51193A02B297329]:0)


FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelExecutorStream

Error Message:
Error from server at http://127.0.0.1:56806/solr/workQueue_shard2_replica_n3: 
Expected mime type application/octet-stream but got text/html.   
 
Error 404HTTP ERROR: 404 Problem 
accessing /solr/workQueue_shard2_replica_n3/update. Reason: Can not 
find: /solr/workQueue_shard2_replica_n3/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:56806/solr/workQueue_shard2_replica_n3: Expected 
mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/workQueue_shard2_replica_n3/update. Reason:
Can not find: /solr/workQueue_shard2_replica_n3/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([404BBBFC6AEE40FA:FD5CCEE553C27DA7]:0)

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/449/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

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

Error Message:
8 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest: 1) Thread[id=17295, 
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[1CC91EE73D3359D0]-EventThread,
 state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)
2) Thread[id=17296, name=zkCallback-2746-thread-1, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)3) Thread[id=17294, 
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[1CC91EE73D3359D0]-SendThread(127.0.0.1:37117),
 state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101)
 at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997)
 at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060)
4) Thread[id=17293, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.lang.Thread.run(Thread.java:748)5) Thread[id=17455, 
name=zkCallback-2746-thread-3, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)6) Thread[id=17519, 
name=zkCallback-2746-thread-5, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)7) Thread[id=17435, 
name=zkCallback-2746-thread-2, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)   
  at 

[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR active-active clusters

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11003:
-

The test failures are irreproducible with the attached seeds; putting extensive 
logging and trying to understand what can be done next.

> Enabling bi-directional CDCR active-active clusters
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: sample-configs.zip, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003-tlogutils.patch
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time. 
> ClusterACollectionA => ClusterBCollectionB | ClusterBCollectionB => 
> ClusterACollectionA.
> The best use-case would be to we keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR active-active clusters

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11003:
-

Ok!

{{CdcrBidirectionalTest}} is failing miserably every now and then while we do 
beast tests. I see:
{code}
o.a.s.h.CdcrReplicator Forwarded 496 updates to target cdcr-cluster1
  [beaster]   2> 19147 ERROR 
(cdcr-replicator-31-thread-1-processing-n:127.0.0.1:46505_solr 
x:cdcr-cluster1_shard1_replica_n1 s:shard1 c:cdcr-cluster1 r:core_node2) 
[n:127.0.0.1:46505_solr c:cdcr-cluster1 s:shard1 r:core_node2 
x:cdcr-cluster1_shard1_replica_n1] o.a.s.c.u.ExecutorUtil Uncaught exception 
java.lang.AssertionError thrown by thread: 
cdcr-replicator-31-thread-1-processing-n:127.0.0.1:46505_solr 
x:cdcr-cluster1_shard1_replica_n1 s:shard1 c:cdcr-cluster1 r:core_node2
  [beaster]   2> java.lang.Exception: Submitter stack trace
  [beaster]   2>at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.execute(ExecutorUtil.java:163)
  [beaster]   2>at 
org.apache.solr.handler.CdcrReplicatorScheduler.lambda$start$1(CdcrReplicatorScheduler.java:76)
  [beaster]   2>at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  [beaster]   2>at 
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
  [beaster]   2>at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  [beaster]   2>at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  [beaster]   2>at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  [beaster]   2>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  [beaster]   2>at java.lang.Thread.run(Thread.java:748)
  [beaster]   2> 19155 INFO  (qtp620825517-65) [n:127.0.0.1:46505_solr 
c:cdcr-cluster1 s:shard1 r:core_node2 x:cdcr-cluster1_shard1_replica_n1] 
o.a.s.c.S.Request [cdcr-cluster1_shard1_replica_n1]  webapp=/solr path=/update 
params={_stateVer_=cdcr-cluster1:5==javabin=2} status=0 
QTime=23
  [beaster]   2> 19156 INFO  
(cdcr-replicator-35-thread-1-processing-n:127.0.0.1:46044_solr 
x:cdcr-cluster2_shard1_replica_n1 s:shard1 c:cdcr-cluster2 r:core_node2) 
[n:127.0.0.1:46044_solr c:cdcr-cluster2 s:shard1 r:core_node2 
x:cdcr-cluster2_shard1_replica_n1] o.a.s.h.CdcrReplicator Forwarded 495 updates 
to target cdcr-cluster1
  [beaster]   2> Sht 21, 2017 6:02:10 PD 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
  [beaster]   2> WARNING: Uncaught exception in thread: 
Thread[cdcr-replicator-31-thread-1,5,TGRP-CdcrBidirectionalTest]
  [beaster]   2> java.lang.AssertionError
  [beaster]   2>at 
__randomizedtesting.SeedInfo.seed([AE4E9FB83368594B]:0)
  [beaster]   2>at 
org.apache.solr.update.TransactionLog$LogReader.next(TransactionLog.java:588)
  [beaster]   2>at 
org.apache.solr.update.CdcrTransactionLog$CdcrLogReader.next(CdcrTransactionLog.java:143)
  [beaster]   2>at 
org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.next(CdcrUpdateLog.java:633)
  [beaster]   2>at 
org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:77)
  [beaster]   2>at 
org.apache.solr.handler.CdcrReplicatorScheduler.lambda$null$0(CdcrReplicatorScheduler.java:81)
  [beaster]   2>at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
  [beaster]   2>at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  [beaster]   2>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  [beaster]   2>at java.lang.Thread.run(Thread.java:748)
  [beaster]   2> 
{code}
Some issue with concurrency in tlogs. some issue with tlog positions.

This results in:
{code}
 [beaster]   2> NOTE: reproduce with: ant test  
-Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
-Dtests.seed=AE4E9FB83368594B -Dtests.slow=true -Dtests.locale=sq-AL 
-Dtests.timezone=Asia/Thimphu -Dtests.asserts=true 
-Dtests.file.encoding=ANSI_X3.4-1968
  [beaster] [00:01:51.287] ERROR   24.8s | CdcrBidirectionalTest.testBiDir <<<
  [beaster]> Throwable #1: java.lang.AssertionError: cluster 2 docs 
mismatch expected:<0> but was:<2>
  [beaster]>at org.junit.Assert.fail(Assert.java:93)
  [beaster]>at org.junit.Assert.failNotEquals(Assert.java:647)
  [beaster]>at org.junit.Assert.assertEquals(Assert.java:128)
  [beaster]>at org.junit.Assert.assertEquals(Assert.java:472)
  [beaster]>at 
org.apache.solr.cloud.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:199)
  [beaster]>at 

[jira] [Updated] (SOLR-11377) Add expMovingAverage (exponential moving average) Stream Evaluator

[Mathew (JIRA)]

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

Mathew updated SOLR-11377:
--
Attachment: SOLR-11377.patch

hey Joel,
Patch contains exponential moving average and binomial coefficient. 

Thanks,
Mathew

> Add expMovingAverage (exponential moving average) Stream Evaluator
> --
>
> Key: SOLR-11377
> URL: https://issues.apache.org/jira/browse/SOLR-11377
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11377.patch
>
>
> This ticket will add the exponential moving average Stream Evaluator.
> Syntax:
> {code}
> expMovingAvg(colA)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10181) CREATEALIAS and DELETEALIAS commands consistency problems under concurrency

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-10181:
--

Thanks Samuel. The right way to fix this is to use ZooKeeper's compare-and-set 
methods to update the /aliases.json. The SolrZkClient's getData method accepts 
a Stat object which returns the version of the znode. Then the setData method 
accepts a version which is used for compare-and-set. If the znode version in ZK 
does not match the version you provide to the client then the client throws a 
BadVersionException. You should catch it and retry the changes until you 
succeed.

> CREATEALIAS and DELETEALIAS commands consistency problems under concurrency
> ---
>
> Key: SOLR-10181
> URL: https://issues.apache.org/jira/browse/SOLR-10181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.3, 5.4, 5.5, 6.4.1
>Reporter: Samuel García Martínez
>Assignee: Erick Erickson
> Attachments: SOLR-10181_testcase.patch
>
>
> When several CREATEALIAS are run at the same time by the OCP it could happen 
> that, even tho the API response is OK, some of those CREATEALIAS request 
> changes are lost.
> h3. The problem
> The problem happens because the CREATEALIAS cmd implementation relies on 
> _zkStateReader.getAliases()_ to create the map that will be stored in ZK. If 
> several threads reach that line at the same time it will happen that only one 
> will be stored correctly and the others will be overridden.
> The code I'm referencing is [this 
> piece|https://github.com/apache/lucene-solr/blob/8c1e67e30e071ceed636083532d4598bf6a8791f/solr/core/src/java/org/apache/solr/cloud/CreateAliasCmd.java#L65].
>  As an example, let's say that the current aliases map has {a:colA, b:colB}. 
> If two CREATEALIAS (one adding c:colC and other creating d:colD) are 
> submitted to the _tpe_ and reach that line at the same time, the resulting 
> maps will look like {a:colA, b:colB, c:colC} and {a:colA, b:colB, d:colD} and 
> only one of them will be stored correctly in ZK, resulting in "data loss", 
> meaning that API is returning OK despite that it didn't work as expected.
> On top of this, another concurrency problem could happen when the command 
> checks if the alias has been set using _checkForAlias_ method. if these two 
> CREATEALIAS zk writes had ran at the same time, the alias check fir one of 
> the threads can timeout since only one of the writes has "survived" and has 
> been "committed" to the _zkStateReader.getAliases()_ map.
> h3. How to fix it
> I can post a patch to this if someone gives me directions on how it should be 
> fixed. As I see this, there are two places where the issue can be fixed: in 
> the processor (OverseerCollectionMessageHandler) in a generic way or inside 
> the command itself.
> h5. The processor fix
> The locking mechanism (_OverseerCollectionMessageHandler#lockTask_) should be 
> the place to fix this inside the processor. I thought that adding the 
> operation name instead of only "collection" or "name" to the locking key 
> would fix the issue, but I realized that the problem will happen anyway if 
> the concurrency happens between different operations modifying the same 
> resource (like CREATEALIAS and DELETEALIAS do). So, if this should be the 
> path to follow I don't know what should be used as a locking key.
> h5. The command fix
> Fixing it at the command level (_CreateAliasCmd_ and _DeleteAliasCmd_) would 
> be relatively easy. Using optimistic locking, i.e, using the aliases.json zk 
> version in the keeper.setData. To do that, Aliases class should offer the 
> aliases version so the commands can forward that version with the update and 
> retry when it fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11278) CdcrBootstrapTest failing intermittently

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar edited comment on SOLR-11278 at 9/20/17 11:49 PM:
---

Uploading another patch which makes sure if we request bootstrap status after 
submitting a bootstrap, we get the correct status: RUNNING. Used CountDownLatch 
internally in the function.


was (Author: sarkaramr...@gmail.com):
Uploading another patch which blocks any other bootstrap call b/w one is 
submitted and executed. Used CountDownLatch internally in the function.

> CdcrBootstrapTest failing intermittently
> 
>
> Key: SOLR-11278
> URL: https://issues.apache.org/jira/browse/SOLR-11278
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.0, 6.6.1
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Critical
>  Labels: test
> Attachments: master-bs.patch, SOLR-11278-awaits-fix.patch, 
> SOLR-11278-cancel-bootstrap-on-stop.patch, SOLR-11278.patch, 
> SOLR-11278.patch, SOLR-11278.patch, test_results
>
>
> {{CdcrBootstrapTest}} is failing while running beasts for significant 
> iterations.
> The bootstrapping is failing in the test, after the first batch is indexed 
> for each {{testmethod}}, which results in documents mismatch ::
> {code}
>   [beaster]   2> 39167 ERROR 
> (updateExecutor-39-thread-1-processing-n:127.0.0.1:42155_solr 
> x:cdcr-target_shard1_replica_n1 s:shard1 c:cdcr-target r:core_node2) 
> [n:127.0.0.1:42155_solr c:cdcr-target s:shard1 r:core_node2 
> x:cdcr-target_shard1_replica_n1] o.a.s.h.CdcrRequestHandler Bootstrap 
> operation failed
>   [beaster]   2> java.util.concurrent.ExecutionException: 
> java.lang.AssertionError
>   [beaster]   2>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   [beaster]   2>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler.lambda$handleBootstrapAction$0(CdcrRequestHandler.java:654)
>   [beaster]   2>  at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>   [beaster]   2>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   [beaster]   2>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   [beaster]   2>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
>   [beaster]   2>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   [beaster]   2>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   [beaster]   2>  at java.lang.Thread.run(Thread.java:748)
>   [beaster]   2> Caused by: java.lang.AssertionError
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:813)
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:724)
>   [beaster]   2>  at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
>   [beaster]   2>  ... 5 more
> {code}
> {code}
>   [beaster] [01:37:16.282] FAILURE  153s | 
> CdcrBootstrapTest.testBootstrapWithSourceCluster <<<
>   [beaster]> Throwable #1: java.lang.AssertionError: Document mismatch on 
> target after sync expected:<2000> but was:<1000>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11278) CdcrBootstrapTest failing intermittently

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11278:

Attachment: SOLR-11278.patch

Uploading another patch which blocks any other bootstrap call b/w one is 
submitted and executed. Used CountDownLatch internally in the function.

> CdcrBootstrapTest failing intermittently
> 
>
> Key: SOLR-11278
> URL: https://issues.apache.org/jira/browse/SOLR-11278
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.0, 6.6.1
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Critical
>  Labels: test
> Attachments: master-bs.patch, SOLR-11278-awaits-fix.patch, 
> SOLR-11278-cancel-bootstrap-on-stop.patch, SOLR-11278.patch, 
> SOLR-11278.patch, SOLR-11278.patch, test_results
>
>
> {{CdcrBootstrapTest}} is failing while running beasts for significant 
> iterations.
> The bootstrapping is failing in the test, after the first batch is indexed 
> for each {{testmethod}}, which results in documents mismatch ::
> {code}
>   [beaster]   2> 39167 ERROR 
> (updateExecutor-39-thread-1-processing-n:127.0.0.1:42155_solr 
> x:cdcr-target_shard1_replica_n1 s:shard1 c:cdcr-target r:core_node2) 
> [n:127.0.0.1:42155_solr c:cdcr-target s:shard1 r:core_node2 
> x:cdcr-target_shard1_replica_n1] o.a.s.h.CdcrRequestHandler Bootstrap 
> operation failed
>   [beaster]   2> java.util.concurrent.ExecutionException: 
> java.lang.AssertionError
>   [beaster]   2>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   [beaster]   2>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler.lambda$handleBootstrapAction$0(CdcrRequestHandler.java:654)
>   [beaster]   2>  at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>   [beaster]   2>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   [beaster]   2>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   [beaster]   2>  at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
>   [beaster]   2>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   [beaster]   2>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   [beaster]   2>  at java.lang.Thread.run(Thread.java:748)
>   [beaster]   2> Caused by: java.lang.AssertionError
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:813)
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:724)
>   [beaster]   2>  at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
>   [beaster]   2>  ... 5 more
> {code}
> {code}
>   [beaster] [01:37:16.282] FAILURE  153s | 
> CdcrBootstrapTest.testBootstrapWithSourceCluster <<<
>   [beaster]> Throwable #1: java.lang.AssertionError: Document mismatch on 
> target after sync expected:<2000> but was:<1000>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11085) Improve resiliency of autoscaling actions

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-11085:
-
Attachment: SOLR-11085.patch

> Improve resiliency of autoscaling actions
> -
>
> Key: SOLR-11085
> URL: https://issues.apache.org/jira/browse/SOLR-11085
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11085.patch
>
>
> We need to improve resiliency of actions against:
> # Overseer restarts
> # Failed operations e.g. a move replica fails if target node is no longer live



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11085) Improve resiliency of autoscaling actions

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11085:
--

Committed to feature/autoscaling branch.

> Improve resiliency of autoscaling actions
> -
>
> Key: SOLR-11085
> URL: https://issues.apache.org/jira/browse/SOLR-11085
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11085.patch
>
>
> We need to improve resiliency of actions against:
> # Overseer restarts
> # Failed operations e.g. a move replica fails if target node is no longer live



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11085) Improve resiliency of autoscaling actions

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-11085:
-
Attachment: (was: SOLR-11085.patch)

> Improve resiliency of autoscaling actions
> -
>
> Key: SOLR-11085
> URL: https://issues.apache.org/jira/browse/SOLR-11085
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (8.0), 7.1
>
>
> We need to improve resiliency of actions against:
> # Overseer restarts
> # Failed operations e.g. a move replica fails if target node is no longer live



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10643) Throttling strategy for triggers and policy executions

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10643:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Throttling strategy for triggers and policy executions
> --
>
> Key: SOLR-10643
> URL: https://issues.apache.org/jira/browse/SOLR-10643
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10643.patch, SOLR-10643.patch, SOLR-10643.patch
>
>
> We must ensure that triggers and policy executions:
> # Do not step on each other's toes by concurrent executions
> # Do not fire/execute too frequently
> # Do not stack up



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10738) TriggerAction is initialised even if the trigger is never scheduled

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10738:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> TriggerAction is initialised even if the trigger is never scheduled
> ---
>
> Key: SOLR-10738
> URL: https://issues.apache.org/jira/browse/SOLR-10738
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10738-fix.patch, SOLR-10738.patch, 
> SOLR-10738-tests.patch
>
>
> The zk watcher responsible for creating triggers creates them blindly without 
> checking if the trigger is actually modified. This is be design as 
> ScheduledTriggers.add is a no-op if the trigger being added is unchanged. 
> However, since the trigger's actions are initialised in the trigger's 
> constructor, they are inited needlessly by the zk watcher thread even though 
> we may never schedule those trigger instances (because they are unchanged). 
> So I propose to change the TriggerAction lifecycle such that the 
> TriggerAction.init is only called when the trigger is actually ready to be 
> scheduled.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10714) OverseerTriggerThread does not start triggers on overseer start until autoscaling config watcher is fired

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10714:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> OverseerTriggerThread does not start triggers on overseer start until 
> autoscaling config watcher is fired
> -
>
> Key: SOLR-10714
> URL: https://issues.apache.org/jira/browse/SOLR-10714
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10714.patch
>
>
> Thanks to [~ab] for catching this. The OverseerTriggerThread only sets a 
> watch but doesn't read trigger information by itself. Therefore no triggers 
> are started on overseer restart until the autoscaling zk node changes and the 
> watcher is fired.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10602) Triggers should be able to restore state from old instances when taking over

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10602:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Triggers should be able to restore state from old instances when taking over
> 
>
> Key: SOLR-10602
> URL: https://issues.apache.org/jira/browse/SOLR-10602
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10602.patch, SOLR-10602.patch
>
>
> Currently if a user modifies a trigger then the old trigger is closed and 
> unscheduled and replaced with a new trigger instance with updated properties. 
> However, this loses the intermediate state that the trigger may have been 
> tracking. For example, say there is a trigger for NodeAdded event with 
> waitFor=5s and a new node is added to the cluster. While the trigger is 
> waiting for 5s before firing, the user modifies the trigger to change the 
> waitFor=2s. Doing this today will erase the state of the old trigger and the 
> new trigger will never fire for the newly added node.
> We need to be able to restore state from old trigger instance before 
> replacing it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10396) Implement trigger support for nodeLost event type

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10396:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Implement trigger support for nodeLost event type
> -
>
> Key: SOLR-10396
> URL: https://issues.apache.org/jira/browse/SOLR-10396
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10396.patch
>
>
> Implement support for 'nodeLost' event type in triggers. This kind of trigger 
> is fired when a node goes away (i.e. no longer live) and does not comes back 
> within a configured amount of time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10965) Implement ExecutePlanAction for autoscaling

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10965:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Implement ExecutePlanAction for autoscaling
> ---
>
> Key: SOLR-10965
> URL: https://issues.apache.org/jira/browse/SOLR-10965
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10965.patch, SOLR-10965.patch
>
>
> The ExecutePlanAction will use cluster operations computed by 
> ComputePlanAction and execute them against the cluster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10496) Implement ComputePlanAction for autoscaling

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10496:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Implement ComputePlanAction for autoscaling
> ---
>
> Key: SOLR-10496
> URL: https://issues.apache.org/jira/browse/SOLR-10496
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, 
> SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, 
> SOLR-10496.patch, SOLR-10496-test2.patch, SOLR-10496-test.patch
>
>
> The ComputePlanAction will use the cluster/collection policy to calculate the 
> cluster operations to be performed. This issue is about integrating the work 
> done in SOLR-10278 with the trigger framework.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10358) Implement suspend-trigger and resume-trigger APIs

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10358:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Implement suspend-trigger and resume-trigger APIs
> -
>
> Key: SOLR-10358
> URL: https://issues.apache.org/jira/browse/SOLR-10358
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10358.patch
>
>
> There are times when the user wants to pause execution of the autoscaling 
> policies because he/she is performing some maintenance tasks. A cluster wide 
> command can be used to suspend the triggers indefinitely or for a specific 
> amount of time.
> h3. Examples:
> Suspend the 'node_lost_trigger' until an explicit resume_trigger API is 
> called:
> {code}
> curl -H 'Content-type:application/json' -d '{
>   "suspend-trigger" : {
>   "name" : "node_lost_trigger"
>   }
> }' http://localhost:8983/solr/admin/autoscaling
> {code}
> Suspend all triggers until resumed by an explicit resume_trigger API call:
> {code}
> curl -H 'Content-type:application/json' -d '{
>   "suspend-trigger" : {
>   "name" : "#EACH"
>   }
> }' http://localhost:8983/solr/admin/autoscaling
> {code}
> Suspend all triggers for 1 hour:
> {code}
> curl -H 'Content-type:application/json' -d '{
>   "suspend-trigger" : {
>   "name" : "#EACH"
>   "timeout" : "1h"
>   }
> }' http://localhost:8983/solr/admin/autoscaling
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10376) Implement trigger for nodeAdded event

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10376:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Implement trigger for nodeAdded event
> -
>
> Key: SOLR-10376
> URL: https://issues.apache.org/jira/browse/SOLR-10376
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR_10376_OverseerTest_fix.patch, SOLR-10376.patch, 
> SOLR-10376.patch, SOLR-10376.patch
>
>
> This issue is about implementing support for the nodeAdded event type. 
> Whenever a node is added, all triggers for this event type should be fired.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10340) Implement set-listener and remove-listener API

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10340:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Implement set-listener and remove-listener API
> --
>
> Key: SOLR-10340
> URL: https://issues.apache.org/jira/browse/SOLR-10340
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10340.patch, SOLR-10340.patch
>
>
> Implement set-listener and remove-listener API to listen to various lifecycle 
> stages of a trigger.
> The set-listeners API can be invoked to add a listener to any trigger at any 
> stage of its execution. The parameters are :
> * ‘name’ - a unique string identifying the listener so that it can be read, 
> updated and removed
> * ‘trigger’ - the name of the trigger to listen to
> * ‘stage’ - the stage of the trigger (multiple values can be specified as an 
> array of strings), possible values are:
> ** STARTED,
> ** ABORTED,
> ** FAILED,
> ** SUCCEEDED
> * ‘beforeAction’ - the action name before which the listener should be 
> notified. Multiple values can be specified as an array of strings.
> * ‘afterAction’ - the action name after which the listener should be 
> notified. Multiple values can be specified as an array of strings
> * ‘class’ - an implementation of ‘TriggerListener’ class
> * Other parameters depend on the listener class
> An example invocation of this API is:
> {code}
> curl -H 'Content-type:application/json' -d '{
> “set-listener” : 
>   {
>   “name” : “xyz”,
>   “trigger” : “node_lost_trigger”,
>   “stage” : [“STARTED”,”ABORTED”,”SUCCEEDED”],
>   “beforeAction” : “execute_plan”,
>   “class” : “solr.HttpCallback”,
>   “url” : 
> “http://xyz.com/on_node_lost?node={$LOST_NODE_NAME}”
> }' http://localhost:8983/solr/admin/cluster
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10339) Implement set-trigger and remove-trigger APIs

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10339:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Implement set-trigger and remove-trigger APIs
> -
>
> Key: SOLR-10339
> URL: https://issues.apache.org/jira/browse/SOLR-10339
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10339.patch, SOLR-10339.patch
>
>
> Implement set-trigger and remove-trigger API to add, update and remove 
> triggers for autoscaling.
> The following events are supported:
> # nodeAdded
> # nodeLost
> # replicaLost
> # schedule
> # searchRate
> # indexRate
> Each trigger has the following properties:
> # ‘name’ - a unique string to identify the trigger so that it can be read, 
> updated or removed later
> # ‘state’ - the state of the event (ENABLED or DISABLED), default is ENABLED. 
> This allows one to add a trigger which is disabled until a RESUME_TRIGGER API 
> is called.
> # ‘actions’ - a list of actions to be performed in the order specified. The 
> default list of actions for every trigger are to compute the plan, execute 
> the plan and save the plan. If an empty list of actions is explicitly 
> specified or null is specified when creating/updating the trigger then no 
> actions are performed at all.
> Here's an example of an API invocation:
> {code}
> {
>   "set-trigger" : {
>   "name" : "node_lost_trigger",
>   "event" : "nodeLost",
>   "waitFor" : "10m",
>   "state" : "ENABLED",
>   "actions" : [
>   {
>   "name" : "compute_plan",
>   "class" : "solr.ComputePlanAction"
>   },
>   {
>   "name" : "execute_plan",
>   "class" : "solr.ExecutePlanAction"
>   },
>   {
>   "name" : "log_plan",
>   "class" : "solr.LogPlanAction",
>   "collection" : ".system"
>   }
>   ]
>   }
> }
> {code}
> Note this issue is only about implementation of the user-facing APIs and not 
> the actual trigger mechanism itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10764) AutoScalingHandler should validate policy and preferences before updating zookeeper

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-10764:
-
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> AutoScalingHandler should validate policy and preferences before updating 
> zookeeper
> ---
>
> Key: SOLR-10764
> URL: https://issues.apache.org/jira/browse/SOLR-10764
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: autoscaling
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10764.patch
>
>
> AutoScalingHandler should validate policy and preferences before updating 
> zookeeper so that problems are caught early rather than during diagnostics or 
> actual executions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

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([60FD4B801913EAF6:E8A9745AB7EF870E]: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:908)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:612)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
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 

[jira] [Updated] (SOLR-11085) Improve resiliency of autoscaling actions

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-11085:
-
Attachment: SOLR-11085.patch

This patch:
# Passes ZkController to the TriggerFactory to avoid running into SOLR-11370. 
Similarily, triggers use the ZkController directly instead of accessing it via 
container.getZkController.
# ExecutePlanAction always calls collection APIs in async mode and uses the 
request id to poll for completion of tasks.
# Fixes a bug in Preference where the setApproxVal method was trying to access 
metrics for non-live nodes leading to NPE.
# ScheduledTriggers:
##  adds more protection against overseer shutdown
## ScheduledTriggers fires listeners for event stage STARTED after the event is 
enqueued successfully to ZK
## ScheduledTriggers waits for pending tasks requested by ExecutePlanAction 
before trying to compute/execute the plan again
# SharedFSAutoReplicaFailoverTest now restarts overseer sometimes and removes 
the nocommit added by SOLR-10397

> Improve resiliency of autoscaling actions
> -
>
> Key: SOLR-11085
> URL: https://issues.apache.org/jira/browse/SOLR-11085
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11085.patch
>
>
> We need to improve resiliency of actions against:
> # Overseer restarts
> # Failed operations e.g. a move replica fails if target node is no longer live



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release 7.0 process starts

[Jan Høydahl]

Now with docs in git this should be within reach with some discipline!
If we don’t manage to get the official refGuide released simultaneously
it’d be just one hour of work to convert the "Major Changes in Solr X”
refguide page into a blog post that could be published on the CMS?

PS: I just updated the “About versions” section of 
http://lucene.apache.org/solr/community.html 

This should probably be part of the RM instructions?

Another observation is that the release announcement mail
should be formatted with a max line length of 75 or something,
to format nicely in ASCII format.

Congrats on the release, everyone!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 20. sep. 2017 kl. 21.29 skrev Cassandra Targett :
> 
> Hijacking this thread a little bit now that Anshum has what he needs
> to release...I wanted to clarify my earlier point about the Ref Guide
> being in sync with the release notes.
> 
> I'd like to see us evolve from our current model of Release Notes ->
> CHANGES.txt and provide an intermediary level of information geared to
> those upgrading. What I wish we could have done is add a link in the
> release notes to the upgrade notes in the Ref Guide instead of
> directing people to CHANGES.
> 
> In order to do this, though, the Ref Guide needs to be released at
> just about the same time. Docs shouldn't be something that starts when
> someone proposes a release, but instead is considered a critical part
> of the actual release. I think most of us nod our heads at that idea,
> but when a vote thread starts, we should be looking for typos instead
> of still chasing down information that could have been written/updated
> when the code change was made.
> 
> People still need CHANGES.txt for their detailed upgrade planning. But
> we can do more to help them make initial plans for their upgrades
> without overwhelming them with detail. And, of course, with a major
> release like 7.0, it would be nice if they had documentation to go
> with it instead of waiting another X weeks.
> 
> Enough of my soapbox - I hope by the time 8.0 is ready to go out we
> are able to publish the Ref Guide with the release. I thought now
> might be a good time to plug for it.
> 
> Cassandra
> 
> On Wed, Sep 20, 2017 at 12:41 PM, Anshum Gupta  wrote:
>> I’ve added a note about the analytics component, and restructured the
>> points.
>> 
>> Thanks to everyone and please don’t make any more changes as I’m adding
>> these to the news section and committing now.
>> 
>> -Anshum
>> 
>> 
>> 
>> On Sep 20, 2017, at 10:30 AM, Anshum Gupta  wrote:
>> 
>> +1 on keeping that section. I just read it wrong I guess, and assumed you
>> wanted to remove that section.
>> 
>> -Anshum
>> 
>> 
>> 
>> On Sep 20, 2017, at 9:55 AM, Joel Bernstein  wrote:
>> 
>> I think we should keep all the typical wording around upgrades. I'm just
>> suggesting an arrangement of the highlights section.
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>> 
>> On Wed, Sep 20, 2017 at 12:43 PM, Anshum Gupta  wrote:
>>> 
>>> Joel, I was actually asking if you meant removing the following section:
>>> 
>>> Being a major release, Solr 7 removes many deprecated APIs, changes
>>> various parameter defaults and
>>> behavior. Some changes may require a re-index of your content. You are
>>> thus encouraged to thoroughly
>>> read the "Upgrade Notes" at
>>> http://lucene.apache.org/solr/7_0_0/changes/Changes.html or in the
>>> CHANGES.txt file accompanying the release.
>>> 
>>> 
>>> Uwe: I am ready with all my (website) changes, and just waiting on the
>>> Solr ‘news’ section that is a subset of the release notes. From the looks of
>>> it, we are done with the changes, and I can copy the relevant sections and
>>> commit the website changes. So yes, the release would happen on the 20th :)
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
>>> On Sep 20, 2017, at 8:34 AM, Joel Bernstein  wrote:
>>> 
>>> I think the release highlights are about what's exciting in the release.
>>> So leading with the most exciting features is the way to go. Informing
>>> people of changes that will affect them can be done in the upgrade notes in
>>> CHANGES.txt.
>>> 
>>> What do other people think about this?
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>> 
>>> On Wed, Sep 20, 2017 at 11:21 AM, Anshum Gupta  wrote:
 
 Also, I think it might make sense to add a line saying that the Ref Guide
 for 7.0 would be released soon.
 
 -Anshum
 
 
 
 On Sep 20, 2017, at 8:20 AM, Anshum Gupta  wrote:
 
 Sounds good.
 
 Also, I am not a java expert like Uwe, and a few others here so let me
 know if we should leave in the ‘Jigsaw’ part.
 
 David, you added that yesterday and Mike looked at the Lucene release

[jira] [Created] (SOLR-11382) Better Geo3d support

[David Smiley (JIRA)]

David Smiley created SOLR-11382:
---

 Summary: Better Geo3d support
 Key: SOLR-11382
 URL: https://issues.apache.org/jira/browse/SOLR-11382
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: spatial
Reporter: David Smiley


LUCENE-7951 added Geo3d support to spatial-extas.  Solr can leverage this 
directly thanks to reflection based construction in Spatial4j but we can do 
better:
* {{spatialContextFactory="geo3d"}} -- a convenience for 
org.apache.lucene.spatial.spatial4j.Geo3dSpatialContextFactory
* test
* documentation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7951) New wrapper classes for Geo3d

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-7951:
-
Attachment: LUCENE-7951.patch

Uploading the patch I intend to commit later tonight.  I made more than trivial 
changes:

* Reverted QueryEqualsHashCodeTest as it has nothing to do with Geo3d and the 
additions duplicated many test lines
* Removed the redundant test lines in SpatialArgsTest so that it simply 
randomly picked the spatial context (potentially Geo3d).
* Geo3dShapeFactory polygon / hole building wasn't quite right; the endHole 
method is supposed to return the PolygonBuilder of the *parent* / containing 
polygon, not some new builder.  Admittedly the Spatial4j javadocs should have 
clarified that.  I fixed this and made simplifications.
* Geo3dShapeFactory addPoint; removed the points.contains(point) check on each 
input point as it's both not necessary (Geo3d internally has a filterPoints 
method/functionality) and expensive (O(N^2)).
* Modified the Geo3dRptTest to not have the factory be a field of the test.  
The factory is supposed to be a very temporary thing only used to create the 
context.
* Auto-formatted most of these source files.
* Removed Geo3dDistanceCalculator.pointOnBearing2 as it was unused
* Geo3dDistanceCalculator.distance: made both variants support Point subclasses 
that aren't Geo3dPointShape

In at least one of these cases the problem was discovered by using it with some 
Solr tests.  I intend to file a separate issue for Solr since it's both a test 
+ convenience (spatialContextFactory="geo3d") + documentation

> New wrapper classes for Geo3d
> -
>
> Key: LUCENE-7951
> URL: https://issues.apache.org/jira/browse/LUCENE-7951
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial-extras
>Reporter: Ignacio Vera
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, 
> LUCENE-7951.patch, LUCENE-7951.patch, LUCENE-7951.patch
>
>
> Hi,
> After the latest developments in the Geo3d library, in particular:
> [https://issues.apache.org/jira/browse/LUCENE-7906] : Spatial relationships 
> between GeoShapes
> [https://issues.apache.org/jira/browse/LUCENE-7936]: Serialization of 
> GeoShapes.
> I propose a new set of wrapper classes which can be for example linked to 
> Solr as they implement their own SpatialContextFactory. It provides the 
> capability of indexing shapes with 
>  spherical geometry.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20506/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testExecutorStream

Error Message:
Error from server at http://127.0.0.1:40777/solr/workQueue_shard2_replica_n3: 
Expected mime type application/octet-stream but got text/html.   
 
Error 404HTTP ERROR: 404 Problem 
accessing /solr/workQueue_shard2_replica_n3/update. Reason: Can not 
find: /solr/workQueue_shard2_replica_n3/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:40777/solr/workQueue_shard2_replica_n3: Expected 
mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/workQueue_shard2_replica_n3/update. Reason:
Can not find: /solr/workQueue_shard2_replica_n3/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([BDDAAEA278A20EE0:9F1A2F595BC824F0]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testExecutorStream(StreamExpressionTest.java:7191)
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 

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-9-ea+181) - Build # 6910 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6910/
Java: 64bit/jdk-9-ea+181 -XX:-UseCompressedOops -XX:+UseG1GC 
--illegal-access=deny

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.SampleTest

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\J1\temp\solr.SampleTest_8C297FEF37D1E19E-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_8C297FEF37D1E19E-001\init-core-data-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_8C297FEF37D1E19E-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_8C297FEF37D1E19E-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\J1\temp\solr.SampleTest_8C297FEF37D1E19E-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_8C297FEF37D1E19E-001\init-core-data-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_8C297FEF37D1E19E-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_8C297FEF37D1E19E-001

at __randomizedtesting.SeedInfo.seed([8C297FEF37D1E19E]: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.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testPoissonDistribution

Error Message:
expected:<99.9552> but was:<96.73466642664324>

Stack Trace:
java.lang.AssertionError: expected:<99.9552> but was:<96.73466642664324>
at 
__randomizedtesting.SeedInfo.seed([E54498F6A03F14B6:7D54675702866CCA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:443)
at org.junit.Assert.assertEquals(Assert.java:512)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testPoissonDistribution(StreamExpressionTest.java:6318)
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 
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)
   

Re: 7.0 docs

[Joel Bernstein]

Ok, my plan right now is to get everything wrapped up by tomorrow night.
I'll check back in and let you know my progress.

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 3:33 PM, Cassandra Targett 
wrote:

> I was just starting my "final" editing review today. Since 7.0 is
> officially released, we should endeavor to get the Ref Guide out ASAP.
>
> Since I've been out for a couple of weeks, I'm not sure the timing
> exactly, but if you need longer than this week, please let me know.
>
> On Wed, Sep 20, 2017 at 12:30 PM, Joel Bernstein 
> wrote:
> > Yes these changes still need to be back ported and the new page needs to
> be
> > referenced as a sister page to Graph Traversal. I planned on doing this
> > before the ref guide released. Now it seems it's time to finish this off.
> >
> > I believe I'll have time this week to finish this. Will that be holding
> up
> > the docs release?
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Sep 20, 2017 at 1:20 PM, Cassandra Targett <
> casstarg...@gmail.com>
> > wrote:
> >>
> >> Hey Joel,
> >>
> >> You made some commits for streaming changes in 7.0 back in August, but
> >> they aren't in branch_7_0 nor branch_7x...did you not backport them?
> >>
> >> It looks all of your edits were to a single new page
> >> "statistical-programming.adoc", but that page is not referenced from
> >> any other page, so since it's not in the hierarchy anywhere it isn't
> >> actually included with the HTML or PDF versions. Were you thinking I
> >> would take care of the rest of the setup of the new page here?
> >>
> >> Also, it seems the new UUID streaming evaluator hasn't yet been
> >> documented. Not sure if you were going to do that or if Dennis was.
> >>
> >> Thanks
> >> Cassandra
> >>
> >> On Wed, Aug 16, 2017 at 12:05 PM, Cassandra Targett
> >>  wrote:
> >> > Thanks Joel!
> >> >
> >> > On Tue, Aug 15, 2017 at 2:10 PM, Joel Bernstein 
> >> > wrote:
> >> >> I wanted to give an update on the 7.0 docs I'm working on.
> >> >>
> >> >> I've just made the first commit for the new Stream Evaluators in
> 7.0. I
> >> >> plan
> >> >> to finish the function documentation by Aug 18th.
> >> >>
> >> >> I also plan to add a new documentation page explaining how the new
> >> >> statistical programming syntax works. I plan to have this committed
> by
> >> >> the
> >> >> 18th as well.
> >> >>
> >> >>
> >> >>
> >> >> Joel Bernstein
> >> >> http://joelsolr.blogspot.com/
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: 7.0 docs

[Cassandra Targett]

I was just starting my "final" editing review today. Since 7.0 is
officially released, we should endeavor to get the Ref Guide out ASAP.

Since I've been out for a couple of weeks, I'm not sure the timing
exactly, but if you need longer than this week, please let me know.

On Wed, Sep 20, 2017 at 12:30 PM, Joel Bernstein  wrote:
> Yes these changes still need to be back ported and the new page needs to be
> referenced as a sister page to Graph Traversal. I planned on doing this
> before the ref guide released. Now it seems it's time to finish this off.
>
> I believe I'll have time this week to finish this. Will that be holding up
> the docs release?
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Sep 20, 2017 at 1:20 PM, Cassandra Targett 
> wrote:
>>
>> Hey Joel,
>>
>> You made some commits for streaming changes in 7.0 back in August, but
>> they aren't in branch_7_0 nor branch_7x...did you not backport them?
>>
>> It looks all of your edits were to a single new page
>> "statistical-programming.adoc", but that page is not referenced from
>> any other page, so since it's not in the hierarchy anywhere it isn't
>> actually included with the HTML or PDF versions. Were you thinking I
>> would take care of the rest of the setup of the new page here?
>>
>> Also, it seems the new UUID streaming evaluator hasn't yet been
>> documented. Not sure if you were going to do that or if Dennis was.
>>
>> Thanks
>> Cassandra
>>
>> On Wed, Aug 16, 2017 at 12:05 PM, Cassandra Targett
>>  wrote:
>> > Thanks Joel!
>> >
>> > On Tue, Aug 15, 2017 at 2:10 PM, Joel Bernstein 
>> > wrote:
>> >> I wanted to give an update on the 7.0 docs I'm working on.
>> >>
>> >> I've just made the first commit for the new Stream Evaluators in 7.0. I
>> >> plan
>> >> to finish the function documentation by Aug 18th.
>> >>
>> >> I also plan to add a new documentation page explaining how the new
>> >> statistical programming syntax works. I plan to have this committed by
>> >> the
>> >> 18th as well.
>> >>
>> >>
>> >>
>> >> Joel Bernstein
>> >> http://joelsolr.blogspot.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

Re: Release 7.0 process starts

[Cassandra Targett]

Hijacking this thread a little bit now that Anshum has what he needs
to release...I wanted to clarify my earlier point about the Ref Guide
being in sync with the release notes.

I'd like to see us evolve from our current model of Release Notes ->
CHANGES.txt and provide an intermediary level of information geared to
those upgrading. What I wish we could have done is add a link in the
release notes to the upgrade notes in the Ref Guide instead of
directing people to CHANGES.

In order to do this, though, the Ref Guide needs to be released at
just about the same time. Docs shouldn't be something that starts when
someone proposes a release, but instead is considered a critical part
of the actual release. I think most of us nod our heads at that idea,
but when a vote thread starts, we should be looking for typos instead
of still chasing down information that could have been written/updated
when the code change was made.

People still need CHANGES.txt for their detailed upgrade planning. But
we can do more to help them make initial plans for their upgrades
without overwhelming them with detail. And, of course, with a major
release like 7.0, it would be nice if they had documentation to go
with it instead of waiting another X weeks.

Enough of my soapbox - I hope by the time 8.0 is ready to go out we
are able to publish the Ref Guide with the release. I thought now
might be a good time to plug for it.

Cassandra

On Wed, Sep 20, 2017 at 12:41 PM, Anshum Gupta  wrote:
> I’ve added a note about the analytics component, and restructured the
> points.
>
> Thanks to everyone and please don’t make any more changes as I’m adding
> these to the news section and committing now.
>
> -Anshum
>
>
>
> On Sep 20, 2017, at 10:30 AM, Anshum Gupta  wrote:
>
> +1 on keeping that section. I just read it wrong I guess, and assumed you
> wanted to remove that section.
>
> -Anshum
>
>
>
> On Sep 20, 2017, at 9:55 AM, Joel Bernstein  wrote:
>
> I think we should keep all the typical wording around upgrades. I'm just
> suggesting an arrangement of the highlights section.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Sep 20, 2017 at 12:43 PM, Anshum Gupta  wrote:
>>
>> Joel, I was actually asking if you meant removing the following section:
>>
>> Being a major release, Solr 7 removes many deprecated APIs, changes
>> various parameter defaults and
>> behavior. Some changes may require a re-index of your content. You are
>> thus encouraged to thoroughly
>> read the "Upgrade Notes" at
>> http://lucene.apache.org/solr/7_0_0/changes/Changes.html or in the
>> CHANGES.txt file accompanying the release.
>>
>>
>> Uwe: I am ready with all my (website) changes, and just waiting on the
>> Solr ‘news’ section that is a subset of the release notes. From the looks of
>> it, we are done with the changes, and I can copy the relevant sections and
>> commit the website changes. So yes, the release would happen on the 20th :)
>>
>> -Anshum
>>
>>
>>
>> On Sep 20, 2017, at 8:34 AM, Joel Bernstein  wrote:
>>
>> I think the release highlights are about what's exciting in the release.
>> So leading with the most exciting features is the way to go. Informing
>> people of changes that will affect them can be done in the upgrade notes in
>> CHANGES.txt.
>>
>> What do other people think about this?
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Wed, Sep 20, 2017 at 11:21 AM, Anshum Gupta  wrote:
>>>
>>> Also, I think it might make sense to add a line saying that the Ref Guide
>>> for 7.0 would be released soon.
>>>
>>> -Anshum
>>>
>>>
>>>
>>> On Sep 20, 2017, at 8:20 AM, Anshum Gupta  wrote:
>>>
>>> Sounds good.
>>>
>>> Also, I am not a java expert like Uwe, and a few others here so let me
>>> know if we should leave in the ‘Jigsaw’ part.
>>>
>>> David, you added that yesterday and Mike looked at the Lucene release
>>> notes and let it stay there. So I was wondering if it’s important/reasonable
>>> enough to highlight in the release notes.
>>>
>>> -Anshum
>>>
>>>
>>>
>>> On Sep 20, 2017, at 8:12 AM, Joel Bernstein  wrote:
>>>
>>> I would also consider changing the order of the list to highlight the
>>> most interesting features.
>>>
>>> If I saw this as the top highlight I would think of this is mainly a
>>> maintenance release.
>>>
>>>
>>> Indented JSON is now the default response format for all APIs,
>>>   pass wt=json and/or indent=off to use the previous unindented XML
>>> format.
>>>
>>>
>>>
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein 
>>> wrote:

 I just made the edit.

 Joel Bernstein
 http://joelsolr.blogspot.com/

 On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein 
 wrote:
>
> For streaming expressions let's go with:
>

Re: [ANNOUNCE] Apache Solr 7.0.0 released

[Anshum Gupta]

It’s strange but something seems to have stripped off all the formatting from 
the announce mail. Here’s a plain text version of the same and hope this is 
more readable.


20 September 2017, Apache Solr™ 7.0.0 available

Solr is the popular, blazing fast, open source NoSQL search platform from the 
Apache Lucene project. Its major features include powerful full-text search, 
hit highlighting, faceted search, dynamic clustering, database integration, 
rich document (e.g., Word, PDF) handling, and geospatial search. Solr is highly 
scalable, providing fault tolerant distributed search and indexing, and powers 
the search and navigation features of many of the world's largest internet 
sites. 

Solr 7.0.0 is available for immediate download at: 
http://lucene.apache.org/solr/mirrors-solr-latest-redir.html 


See http://lucene.apache.org/solr/7_0_0/changes/Changes.html 
 for a full list of 
details. 

  * Replica Types - Solr 7 supports different replica types, which handle 
updates differently. In addition to pure NRT operation where all replicas build 
an index and keep a replication log, you can now also add so called PULL 
replicas, achieving the read-speed optimized benefits of a master/slave setup 
while at the same time keeping index redundancy. 

  * Auto-scaling. Solr can now allocate new replicas to nodes using a new auto 
scaling policy framework. This framework will in future releases enable Solr to 
move shards around based on load, disk etc. 

  * Indented JSON is now the default response format for all APIs, pass wt=xml 
and/or indent=off to use the previous unindented XML format. 

  * The JSON Facet API now supports two-phase facet refinement to ensure 
accurate counts and statistics for facet buckets returned in distributed mode. 

  * Streaming Expressions adds a new statistical programming syntax for the 
statistical analysis of sql queries, random samples, time series and graph 
result sets. 

  * Analytics Component version 2.0, which now supports distributed 
collections, expressions over multivalued fields, a new JSON request language, 
and more. 

  * The new v2 API, exposed at /api/ and also supported via SolrJ, is now the 
preferred API, but /solr/ continues to work. 

  * A new '_default' configset is used if no config is specified at collection 
creation. The data-driven functionality of this configset indexes strings as 
analyzed text while at the same time copying to a '*_str' field suitable for 
faceting. 

  * Solr 7 is tested with and verified to support Java 9. 

Being a major release, Solr 7 removes many deprecated APIs, changes various 
parameter defaults and behavior. Some changes may require a re-index of your 
content. You are thus encouraged to thoroughly read the "Upgrade Notes" at 
http://lucene.apache.org/solr/7_0_0/changes/Changes.html 
 or in the 
CHANGES.txt file accompanying the release. 

Solr 7.0.0 also includes many other new features as well as numerous 
optimizations and bugfixes of the corresponding Apache Lucene release. 

Please report any feedback to the mailing lists 
(http://lucene.apache.org/solr/discussion.html 
) 

Note: The Apache Software Foundation uses an extensive mirroring network for 
distributing releases. It is possible that the mirror you are using may not 
have replicated the release yet. If that is the case, please try another 
mirror. This also goes for Maven access.

-Anshum



> On Sep 20, 2017, at 12:09 PM, Anshum Gupta  wrote:
> 
> 20 September 2017, Apache Solr™ 7.0.0 available
> 
> Solr is the popular, blazing fast, open source NoSQL search platform from the 
> Apache Lucene project. Its major features include powerful full-text search, 
> hit highlighting, faceted search, dynamic clustering, database integration, 
> rich document (e.g., Word, PDF) handling, and geospatial search. Solr is 
> highly scalable, providing fault tolerant distributed search and indexing, 
> and powers the search and navigation features of many of the world's largest 
> internet sites. 
> 
> Solr 7.0.0 is available for immediate download at: 
> http://lucene.apache.org/solr/mirrors-solr-latest-redir.html 
> 
> See http://lucene.apache.org/solr/7_0_0/changes/Changes.html 
>  for a full list of 
> details. 
> 
> Replica Types - Solr 7 supports different replica types, which handle updates 
> differently. In addition to pure NRT operation where all replicas build an 
> index and keep a replication log, you can now also add so called PULL 
> replicas, achieving the read-speed optimized benefits of a master/slave setup 
> while at the same time keeping index redundancy. 
> Auto-scaling. Solr can now 

[ANNOUNCE] Apache Solr 7.0.0 released

[Anshum Gupta]

20 September 2017, Apache Solr™ 7.0.0 available

Solr is the popular, blazing fast, open source NoSQL search platform from the 
Apache Lucene project. Its major features include powerful full-text search, 
hit highlighting, faceted search, dynamic clustering, database integration, 
rich document (e.g., Word, PDF) handling, and geospatial search. Solr is highly 
scalable, providing fault tolerant distributed search and indexing, and powers 
the search and navigation features of many of the world's largest internet 
sites. 

Solr 7.0.0 is available for immediate download at: 
http://lucene.apache.org/solr/mirrors-solr-latest-redir.html 

See http://lucene.apache.org/solr/7_0_0/changes/Changes.html 
 for a full list of 
details. 

Replica Types - Solr 7 supports different replica types, which handle updates 
differently. In addition to pure NRT operation where all replicas build an 
index and keep a replication log, you can now also add so called PULL replicas, 
achieving the read-speed optimized benefits of a master/slave setup while at 
the same time keeping index redundancy. 
Auto-scaling. Solr can now allocate new replicas to nodes using a new auto 
scaling policy framework. This framework will in future releases enable Solr to 
move shards around based on load, disk etc. 
Indented JSON is now the default response format for all APIs, pass wt=xml 
and/or indent=off to use the previous unindented XML format. 
The JSON Facet API now supports two-phase facet refinement to ensure accurate 
counts and statistics for facet buckets returned in distributed mode. 
Streaming Expressions adds a new statistical programming syntax for the 
statistical analysis of sql queries, random samples, time series and graph 
result sets. 
Analytics Component version 2.0, which now supports distributed collections, 
expressions over multivalued fields, a new JSON request language, and more. 
The new v2 API, exposed at /api/ and also supported via SolrJ, is now the 
preferred API, but /solr/ continues to work. 
A new '_default' configset is used if no config is specified at collection 
creation. The data-driven functionality of this configset indexes strings as 
analyzed text while at the same time copying to a '*_str' field suitable for 
faceting. 
Solr 7 is tested with and verified to support Java 9. 
Being a major release, Solr 7 removes many deprecated APIs, changes various 
parameter defaults and behavior. Some changes may require a re-index of your 
content. You are thus encouraged to thoroughly read the "Upgrade Notes" at 
http://lucene.apache.org/solr/7_0_0/changes/Changes.html 
 or in the 
CHANGES.txt file accompanying the release. 

Solr 7.0.0 also includes many other new features as well as numerous 
optimizations and bugfixes of the corresponding Apache Lucene release. 

Please report any feedback to the mailing lists 
(http://lucene.apache.org/solr/discussion.html 
) 

Note: The Apache Software Foundation uses an extensive mirroring network for 
distributing releases. It is possible that the mirror you are using may not 
have replicated the release yet. If that is the case, please try another 
mirror. This also goes for Maven access.


Anshum Gupta

[ANNOUNCE] Apache Lucene 7.0.0 released

[Anshum Gupta]

20 September 2017, Apache Lucene™ 7.0.0 available

The Lucene PMC is pleased to announce the release of Apache Lucene 7.0.0. 

Apache Lucene is a high-performance, full-featured text search engine library 
written entirely in Java. It is a technology suitable for nearly any 
application that requires full-text search, especially cross-platform. 

This release contains numerous bug fixes, optimizations, and improvements, some 
of which are highlighted below. The release is available for immediate download 
at: http://lucene.apache.org/core/mirrors-core-latest-redir.html 
 

Please read CHANGES.txt for a full list of new features and changes: 
https://lucene.apache.org/core/7_0_0/changes/Changes.html 

Lucene 7.0.0 Release Highlights: 

Doc values switched from random access to iterators. 
The 7.0 codec now sparsely encodes sparse doc values and length normalization 
factors ("norms"), which also translates to optimization in both indexing, and 
search on sparse values. With these changes, you finally only pay for what you 
actually use with doc values, in index size, indexing performance, etc. 
Index time boost for documents is now removed. 
Substantial performance gains for delete and update heavy Lucene usage; see 
http://blog.mikemccandless.com/2017/07/lucene-gets-concurrent-deletes-and.html 

 for details 
Query scoring is now simpler with removal of coord factor, and query 
normalization. 
Classic query parser no longer splits on whitespaces. This enables better 
multi-word synonym support. 
The version of Lucene that created the index segment would be recorded, along 
with the version that last modified the index. 
IndexWriter, used to add, update and delete documents in your index, will no 
longer accept broken token offsets sometimes produced by mis-behaving token 
filters. 
IndexReader exposes methods that are typically used to manage resources whose 
lifetime needs to mimic the lifetime of segments/indexes, typically caches. 
They have been made much less trappy. 
The dimensional points API now takes a field name up front to offer per-field 
points access, matching how the doc values APIs work. 
The PostingsHighlighter was removed. Migrating to the UnifiedHighlighter 
 should be 
straight-forward. 
Apache Lucene was tested to be fully compatible with the release of Java 9 and 
its module system Jigsaw, coming out tomorrow on September 21st! 

Further details of changes are available in the change log available at: 
http://lucene.apache.org/core/7_0_0/changes/Changes.html 

To read more about the changes, also see: 
http://blog.mikemccandless.com/2017/03/apache-lucene-70-is-coming-soon.html 

Please report any feedback to the mailing lists 
(http://lucene.apache.org/core/discussion.html 
) 

Note: The Apache Software Foundation uses an extensive mirroring network for 
distributing releases. It is possible that the mirror you are using may not 
have replicated the release yet. If that is the case, please try another 
mirror. This also applies to Maven access. 

ReleaseNote70 (last edited 2017-09-20 10:27:30 by AnshumGupta 
)
Anshum Gupta

[JENKINS-EA] Lucene-Solr-7.x-Linux (32bit/jdk-9-ea+181) - Build # 447 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/447/
Java: 32bit/jdk-9-ea+181 -server -XX:+UseParallelGC --illegal-access=deny

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup

Error Message:
 null Live Nodes: [127.0.0.1:43177_solr] Last available state: 
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
   "pullReplicas":"0",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   
"replicas":{"core_node2":{   
"core":"testRepFactor1LeaderStartup_shard1_replica_n1",   
"base_url":"https://127.0.0.1:43177/solr;,   
"node_name":"127.0.0.1:43177_solr",   "state":"active",   
"type":"NRT",   "leader":"true",   "router":{"name":"compositeId"}, 
  "maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: 
null
Live Nodes: [127.0.0.1:43177_solr]
Last available state: 
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
  "pullReplicas":"0",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{"core_node2":{
  "core":"testRepFactor1LeaderStartup_shard1_replica_n1",
  "base_url":"https://127.0.0.1:43177/solr;,
  "node_name":"127.0.0.1:43177_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([7087939EFF38EC67:A7AFDE46EED8A589]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup(TestCloudSearcherWarming.java:126)
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 
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 

[JENKINS] Lucene-Solr-Tests-master - Build # 2103 - Still unstable

[Apache Jenkins Server]

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

14 tests failed.
FAILED:  org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithSourceCluster

Error Message:
Captured an uncaught exception in thread: Thread[id=14845, name=Thread-3484, 
state=RUNNABLE, group=TGRP-CdcrBootstrapTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=14845, name=Thread-3484, state=RUNNABLE, 
group=TGRP-CdcrBootstrapTest]
at 
__randomizedtesting.SeedInfo.seed([4A7ECA3F1D8FF724:93289BFB1EEBE46E]:0)
Caused by: java.lang.AssertionError: 1
at __randomizedtesting.SeedInfo.seed([4A7ECA3F1D8FF724]:0)
at 
org.apache.solr.core.CachingDirectoryFactory.close(CachingDirectoryFactory.java:192)
at org.apache.solr.core.SolrCore.close(SolrCore.java:1613)
at 
org.apache.solr.core.CoreContainer.registerCore(CoreContainer.java:863)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1236)
at 
org.apache.solr.handler.IndexFetcher.lambda$reloadCore$0(IndexFetcher.java:900)
at java.lang.Thread.run(Thread.java:748)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.CdcrBootstrapTest

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, 
MockDirectoryWrapper, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:478)  
at org.apache.solr.core.SolrCore.(SolrCore.java:928)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:843)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1002)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:938)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:745)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:726)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:507)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  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.gzip.GzipHandler.handle(GzipHandler.java:426)  
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:283)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)  at 
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 

[jira] [Resolved] (SOLR-11324) Clean up mention of trie fields in documentation and source comments

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-11324.
---
Resolution: Fixed

> Clean up mention of trie fields in documentation and source comments
> 
>
> Key: SOLR-11324
> URL: https://issues.apache.org/jira/browse/SOLR-11324
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11324.patch
>
>
> Mention of trie fields should be removed where feasible from docs and source 
> comments.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/196/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.cloud.CdcrVersionReplicationTest.testCdcrDocVersions

Error Message:
Could not find collection:source_collection

Stack Trace:
java.lang.AssertionError: Could not find collection:source_collection
at 
__randomizedtesting.SeedInfo.seed([C951F609C3E4B85A:31C7FDAB31825746]: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.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:518)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.createSourceCollection(BaseCdcrDistributedZkTest.java:360)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.baseBefore(BaseCdcrDistributedZkTest.java:176)
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$9.evaluate(RandomizedRunner.java:968)
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 

[jira] [Created] (SOLR-11381) HdfsDirectoryFactory throws NPE on cleanup because file system has been closed

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-11381:


 Summary: HdfsDirectoryFactory throws NPE on cleanup because file 
system has been closed
 Key: SOLR-11381
 URL: https://issues.apache.org/jira/browse/SOLR-11381
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: hdfs
Reporter: Shalin Shekhar Mangar
Priority: Trivial
 Fix For: master (8.0), 7.1


I saw this happening on tests related to autoscaling. The old directory clean 
up is triggered on core close in a separate thread. This can cause a race 
condition where the filesystem is closed before the cleanup starts running. 
Then a NPE is thrown and cleanup fails.

Fixing the NPE is simple but I think this is a real bug where old directories 
can be left around on HDFS. I don't know enough about HDFS to investigate 
further. Leaving it here for interested people to pitch in.

{code}
105029 ERROR 
(OldIndexDirectoryCleanupThreadForCore-control_collection_shard1_replica_n1) 
[n:127.0.0.1:58542_ c:control_collection s:shard1 r:core_node2 
x:control_collection_shard1_replica_n1] o.a.s.c.HdfsDirectoryFactory Error 
checking for old index directories to clean-up.
java.io.IOException: Filesystem closed
at org.apache.hadoop.hdfs.DFSClient.checkOpen(DFSClient.java:808)
at org.apache.hadoop.hdfs.DFSClient.listPaths(DFSClient.java:2083)
at org.apache.hadoop.hdfs.DFSClient.listPaths(DFSClient.java:2069)
at 
org.apache.hadoop.hdfs.DistributedFileSystem.listStatusInternal(DistributedFileSystem.java:791)
at 
org.apache.hadoop.hdfs.DistributedFileSystem.access$700(DistributedFileSystem.java:106)
at 
org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:853)
at 
org.apache.hadoop.hdfs.DistributedFileSystem$18.doCall(DistributedFileSystem.java:849)
at 
org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at 
org.apache.hadoop.hdfs.DistributedFileSystem.listStatus(DistributedFileSystem.java:860)
at org.apache.hadoop.fs.FileSystem.listStatus(FileSystem.java:1517)
at org.apache.hadoop.fs.FileSystem.listStatus(FileSystem.java:1557)
at 
org.apache.solr.core.HdfsDirectoryFactory.cleanupOldIndexDirectories(HdfsDirectoryFactory.java:540)
at 
org.apache.solr.core.SolrCore.lambda$cleanupOldIndexDirectories$32(SolrCore.java:3019)
at java.lang.Thread.run(Thread.java:745)
105030 ERROR 
(OldIndexDirectoryCleanupThreadForCore-control_collection_shard1_replica_n1) 
[n:127.0.0.1:58542_ c:control_collection s:shard1 r:core_node2 
x:control_collection_shard1_replica_n1] o.a.s.c.SolrCore Failed to cleanup old 
index directories for core control_collection_shard1_replica_n1
java.lang.NullPointerException
at 
org.apache.solr.core.HdfsDirectoryFactory.cleanupOldIndexDirectories(HdfsDirectoryFactory.java:558)
at 
org.apache.solr.core.SolrCore.lambda$cleanupOldIndexDirectories$32(SolrCore.java:3019)
at java.lang.Thread.run(Thread.java:745)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11297:
---

OK, I poked at this yesterday and my bright idea of moving things to 
createCoreFromDescriptor doesn't work. getCore is the problem, it depends on 
getting the core back from waitAddPendingCoreOps if some other thread is 
opening the core. If we put some kind of test in getCore instead (say 
isCoreInPending() or something), then later in that method called 
createCoreFromDescriptor (assuming the core wasn't in pending ops), it'd be 
possible that another process would open the core between the calls.

There are three places in CoreContainer that call createCoreFromDescriptor 
without being surrounded by a waitAddPendingCoreOps/removeFromPendingOps, I'm 
working up a patch for the other two.

We'll see if it fixes Shawn's problem too, vetting it a bit more now and will 
put up a patch later today if all goes well.

> Message "Lock held by this virtual machine" during startup.  Solr is trying 
> to start some cores twice
> -
>
> Key: SOLR-11297
> URL: https://issues.apache.org/jira/browse/SOLR-11297
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
> Attachments: SOLR-11297.patch, SOLR-11297.sh, solr6_6-startup.log
>
>
> Sometimes when Solr is restarted, I get some "lock held by this virtual 
> machine" messages in the log, and the admin UI has messages about a failure 
> to open a new searcher.  It doesn't happen on all cores, and the list of 
> cores that have the problem changes on subsequent restarts.  The cores that 
> exhibit the problems are working just fine -- the first core load is 
> successful, the failure to open a new searcher is on a second core load 
> attempt, which fails.
> None of the cores in the system are sharing an instanceDir or dataDir.  This 
> has been verified several times.
> The index is sharded manually, and the servers are not running in cloud mode.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release 7.0 process starts

[Anshum Gupta]

I’ve added a note about the analytics component, and restructured the points. 

Thanks to everyone and please don’t make any more changes as I’m adding these 
to the news section and committing now.

-Anshum



> On Sep 20, 2017, at 10:30 AM, Anshum Gupta  wrote:
> 
> +1 on keeping that section. I just read it wrong I guess, and assumed you 
> wanted to remove that section.
> 
> -Anshum
> 
> 
> 
>> On Sep 20, 2017, at 9:55 AM, Joel Bernstein > > wrote:
>> 
>> I think we should keep all the typical wording around upgrades. I'm just 
>> suggesting an arrangement of the highlights section.
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ 
>> 
>> On Wed, Sep 20, 2017 at 12:43 PM, Anshum Gupta > > wrote:
>> Joel, I was actually asking if you meant removing the following section:
>> 
>> Being a major release, Solr 7 removes many deprecated APIs, changes various 
>> parameter defaults and
>> behavior. Some changes may require a re-index of your content. You are thus 
>> encouraged to thoroughly
>> read the "Upgrade Notes" at 
>> http://lucene.apache.org/solr/7_0_0/changes/Changes.html 
>>  or in the
>> CHANGES.txt file accompanying the release.
>> 
>> Uwe: I am ready with all my (website) changes, and just waiting on the Solr 
>> ‘news’ section that is a subset of the release notes. From the looks of it, 
>> we are done with the changes, and I can copy the relevant sections and 
>> commit the website changes. So yes, the release would happen on the 20th :)
>> 
>> -Anshum
>> 
>> 
>> 
>>> On Sep 20, 2017, at 8:34 AM, Joel Bernstein >> > wrote:
>>> 
>>> I think the release highlights are about what's exciting in the release. So 
>>> leading with the most exciting features is the way to go. Informing people 
>>> of changes that will affect them can be done in the upgrade notes in 
>>> CHANGES.txt.
>>> 
>>> What do other people think about this?
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ 
>>> 
>>> On Wed, Sep 20, 2017 at 11:21 AM, Anshum Gupta >> > wrote:
>>> Also, I think it might make sense to add a line saying that the Ref Guide 
>>> for 7.0 would be released soon.
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
 On Sep 20, 2017, at 8:20 AM, Anshum Gupta > wrote:
 
 Sounds good.
 
 Also, I am not a java expert like Uwe, and a few others here so let me 
 know if we should leave in the ‘Jigsaw’ part.
 
 David, you added that yesterday and Mike looked at the Lucene release 
 notes and let it stay there. So I was wondering if it’s 
 important/reasonable enough to highlight in the release notes.
 
 -Anshum
 
 
 
> On Sep 20, 2017, at 8:12 AM, Joel Bernstein  > wrote:
> 
> I would also consider changing the order of the list to highlight the 
> most interesting features.
> 
> If I saw this as the top highlight I would think of this is mainly a 
> maintenance release. 
> 
> 
> Indented JSON is now the default response format for all APIs,
>   pass wt=json and/or indent=off to use the previous unindented XML 
> format.
> 
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein  > wrote:
> I just made the edit.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein  > wrote:
> For streaming expressions let's go with:
> 
> Solr 7 Streaming Expressions adds a new statistical programming syntax for
> the statistical analysis of sql queries, random samples, time series and
> graph result sets.
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
> > wrote:
> Cool. How about 7th and 8th bullet points like this. 8th bullet ending in 
> Java 9 future magic still, not that the magic counts but fitting things 
> on roughly a screen full for folks to easily get the gist of the new 
> release is important I think.
> 
> -Christine
> 
> * Solr 7 adds Streaming Expressions, a new statistical programming syntax 
> for
>   the statistical analysis of sql queries, random samples, time series and
>   graph result sets.

[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8389:
-

Sounds great! Looking forward to it.

> Convert CDCR peer cluster and other configurations into collection properties 
> modifiable via APIs
> -
>
> Key: SOLR-8389
> URL: https://issues.apache.org/jira/browse/SOLR-8389
> Project: Solr
>  Issue Type: Improvement
>  Components: CDCR, SolrCloud
>Reporter: Shalin Shekhar Mangar
>
> CDCR configuration is kept inside solrconfig.xml which makes it difficult to 
> add or change peer cluster configuration.
> I propose to move all CDCR config to collection level properties in cluster 
> state so that they can be modified using the existing modify collection API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release 7.0 process starts

[Anshum Gupta]

+1 on keeping that section. I just read it wrong I guess, and assumed you 
wanted to remove that section.

-Anshum



> On Sep 20, 2017, at 9:55 AM, Joel Bernstein  wrote:
> 
> I think we should keep all the typical wording around upgrades. I'm just 
> suggesting an arrangement of the highlights section.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 12:43 PM, Anshum Gupta  > wrote:
> Joel, I was actually asking if you meant removing the following section:
> 
> Being a major release, Solr 7 removes many deprecated APIs, changes various 
> parameter defaults and
> behavior. Some changes may require a re-index of your content. You are thus 
> encouraged to thoroughly
> read the "Upgrade Notes" at 
> http://lucene.apache.org/solr/7_0_0/changes/Changes.html 
>  or in the
> CHANGES.txt file accompanying the release.
> 
> Uwe: I am ready with all my (website) changes, and just waiting on the Solr 
> ‘news’ section that is a subset of the release notes. From the looks of it, 
> we are done with the changes, and I can copy the relevant sections and commit 
> the website changes. So yes, the release would happen on the 20th :)
> 
> -Anshum
> 
> 
> 
>> On Sep 20, 2017, at 8:34 AM, Joel Bernstein > > wrote:
>> 
>> I think the release highlights are about what's exciting in the release. So 
>> leading with the most exciting features is the way to go. Informing people 
>> of changes that will affect them can be done in the upgrade notes in 
>> CHANGES.txt.
>> 
>> What do other people think about this?
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ 
>> 
>> On Wed, Sep 20, 2017 at 11:21 AM, Anshum Gupta > > wrote:
>> Also, I think it might make sense to add a line saying that the Ref Guide 
>> for 7.0 would be released soon.
>> 
>> -Anshum
>> 
>> 
>> 
>>> On Sep 20, 2017, at 8:20 AM, Anshum Gupta >> > wrote:
>>> 
>>> Sounds good.
>>> 
>>> Also, I am not a java expert like Uwe, and a few others here so let me know 
>>> if we should leave in the ‘Jigsaw’ part.
>>> 
>>> David, you added that yesterday and Mike looked at the Lucene release notes 
>>> and let it stay there. So I was wondering if it’s important/reasonable 
>>> enough to highlight in the release notes.
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
 On Sep 20, 2017, at 8:12 AM, Joel Bernstein > wrote:
 
 I would also consider changing the order of the list to highlight the most 
 interesting features.
 
 If I saw this as the top highlight I would think of this is mainly a 
 maintenance release. 
 
 
 Indented JSON is now the default response format for all APIs,
   pass wt=json and/or indent=off to use the previous unindented XML format.
 
 
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein > wrote:
 I just made the edit.
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein > wrote:
 For streaming expressions let's go with:
 
 Solr 7 Streaming Expressions adds a new statistical programming syntax for
 the statistical analysis of sql queries, random samples, time series and
 graph result sets.
 
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
 > wrote:
 Cool. How about 7th and 8th bullet points like this. 8th bullet ending in 
 Java 9 future magic still, not that the magic counts but fitting things on 
 roughly a screen full for folks to easily get the gist of the new release 
 is important I think.
 
 -Christine
 
 * Solr 7 adds Streaming Expressions, a new statistical programming syntax 
 for
   the statistical analysis of sql queries, random samples, time series and
   graph result sets.
 
 * Solr 7 is tested with and verified to support Java 9
 
 From: dev@lucene.apache.org  At: 09/20/17 
 15:54:54
 To:  Christine Poerschke (BLOOMBERG/ LONDON )  
 ,  dev@lucene.apache.org 
 
 
 Subject: Re: Release 7.0 process starts
 This looks good, other than the wt=xml correction in #1, as Varun pointed 
 out. 

Re: 7.0 docs

[Joel Bernstein]

Yes these changes still need to be back ported and the new page needs to be
referenced as a sister page to Graph Traversal. I planned on doing this
before the ref guide released. Now it seems it's time to finish this off.

I believe I'll have time this week to finish this. Will that be holding up
the docs release?


Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 1:20 PM, Cassandra Targett 
wrote:

> Hey Joel,
>
> You made some commits for streaming changes in 7.0 back in August, but
> they aren't in branch_7_0 nor branch_7x...did you not backport them?
>
> It looks all of your edits were to a single new page
> "statistical-programming.adoc", but that page is not referenced from
> any other page, so since it's not in the hierarchy anywhere it isn't
> actually included with the HTML or PDF versions. Were you thinking I
> would take care of the rest of the setup of the new page here?
>
> Also, it seems the new UUID streaming evaluator hasn't yet been
> documented. Not sure if you were going to do that or if Dennis was.
>
> Thanks
> Cassandra
>
> On Wed, Aug 16, 2017 at 12:05 PM, Cassandra Targett
>  wrote:
> > Thanks Joel!
> >
> > On Tue, Aug 15, 2017 at 2:10 PM, Joel Bernstein 
> wrote:
> >> I wanted to give an update on the 7.0 docs I'm working on.
> >>
> >> I've just made the first commit for the new Stream Evaluators in 7.0. I
> plan
> >> to finish the function documentation by Aug 18th.
> >>
> >> I also plan to add a new documentation page explaining how the new
> >> statistical programming syntax works. I plan to have this committed by
> the
> >> 18th as well.
> >>
> >>
> >>
> >> Joel Bernstein
> >> http://joelsolr.blogspot.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: 7.0 docs

[Cassandra Targett]

Hey Joel,

You made some commits for streaming changes in 7.0 back in August, but
they aren't in branch_7_0 nor branch_7x...did you not backport them?

It looks all of your edits were to a single new page
"statistical-programming.adoc", but that page is not referenced from
any other page, so since it's not in the hierarchy anywhere it isn't
actually included with the HTML or PDF versions. Were you thinking I
would take care of the rest of the setup of the new page here?

Also, it seems the new UUID streaming evaluator hasn't yet been
documented. Not sure if you were going to do that or if Dennis was.

Thanks
Cassandra

On Wed, Aug 16, 2017 at 12:05 PM, Cassandra Targett
 wrote:
> Thanks Joel!
>
> On Tue, Aug 15, 2017 at 2:10 PM, Joel Bernstein  wrote:
>> I wanted to give an update on the 7.0 docs I'm working on.
>>
>> I've just made the first commit for the new Stream Evaluators in 7.0. I plan
>> to finish the function documentation by Aug 18th.
>>
>> I also plan to add a new documentation page explaining how the new
>> statistical programming syntax works. I plan to have this committed by the
>> 18th as well.
>>
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/

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

Re: Release 7.0 process starts

[Joel Bernstein]

I think we should keep all the typical wording around upgrades. I'm just
suggesting an arrangement of the highlights section.

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 12:43 PM, Anshum Gupta  wrote:

> Joel, I was actually asking if you meant removing the following section:
>
> Being a major release, Solr 7 removes many deprecated APIs, changes various 
> parameter defaults andbehavior. Some changes may require a re-index of your 
> content. You are thus encouraged to thoroughlyread the "Upgrade Notes" at 
> http://lucene.apache.org/solr/7_0_0/changes/Changes.html or in theCHANGES.txt 
> file accompanying the release.
>
>
> Uwe: I am ready with all my (website) changes, and just waiting on the
> Solr ‘news’ section that is a subset of the release notes. From the looks
> of it, we are done with the changes, and I can copy the relevant sections
> and commit the website changes. So yes, the release would happen on the
> 20th :)
>
> -Anshum
>
>
>
> On Sep 20, 2017, at 8:34 AM, Joel Bernstein  wrote:
>
> I think the release highlights are about what's exciting in the release.
> So leading with the most exciting features is the way to go. Informing
> people of changes that will affect them can be done in the upgrade notes in
> CHANGES.txt.
>
> What do other people think about this?
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Sep 20, 2017 at 11:21 AM, Anshum Gupta  wrote:
>
>> Also, I think it might make sense to add a line saying that the Ref Guide
>> for 7.0 would be released soon.
>>
>> -Anshum
>>
>>
>>
>> On Sep 20, 2017, at 8:20 AM, Anshum Gupta  wrote:
>>
>> Sounds good.
>>
>> Also, I am not a java expert like Uwe, and a few others here so let me
>> know if we should leave in the ‘Jigsaw’ part.
>>
>> David, you added that yesterday and Mike looked at the Lucene release
>> notes and let it stay there. So I was wondering if it’s
>> important/reasonable enough to highlight in the release notes.
>>
>> -Anshum
>>
>>
>>
>> On Sep 20, 2017, at 8:12 AM, Joel Bernstein  wrote:
>>
>> I would also consider changing the order of the list to highlight the
>> most interesting features.
>>
>> If I saw this as the top highlight I would think of this is mainly a
>> maintenance release.
>>
>>
>> Indented JSON is now the default response format for all APIs,  pass wt=json 
>> and/or indent=off to use the previous unindented XML format.
>>
>>
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein 
>> wrote:
>>
>>> I just made the edit.
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein 
>>> wrote:
>>>
 For streaming expressions let's go with:

 Solr 7 Streaming Expressions adds a new statistical programming syntax
 for
 the statistical analysis of sql queries, random samples, time series and
 graph result sets.


 Joel Bernstein
 http://joelsolr.blogspot.com/

 On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/
 LONDON)  wrote:

> Cool. How about 7th and 8th bullet points like this. 8th bullet
> ending in Java 9 future magic still, not that the magic counts but fitting
> things on roughly a screen full for folks to easily get the gist of the 
> new
> release is important I think.
>
> -Christine
>
> * Solr 7 adds Streaming Expressions, a new statistical programming
> syntax for
> the statistical analysis of sql queries, random samples, time series
> and
> graph result sets.
>
> * Solr 7 is tested with and verified to support Java 9
>
> From: dev@lucene.apache.org At: 09/20/17 15:54:54
> To: Christine Poerschke (BLOOMBERG/ LONDON )
> , dev@lucene.apache.org
>
> Subject: Re: Release 7.0 process starts
>
> This looks good, other than the wt=xml correction in #1, as Varun
> pointed out. Also, I really think we should highlight streaming 
> expressions
> (Math Engine) even if that means we don’t hit the ‘7 points’ mark :).
>
> -Anshum
>
>
>
> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>
> Below is the revised draft I came up with:
>
> (Notice that v2 is the 2nd bullet, though I think it yet needs to
> mention one or _two_ benefits of using the new API especially since we
> mention that /solr/ continues to work.)
>
> (Also notice some re-ordering of the bullets starting with the
> used-by-many JSON first, then v2 API second, then third collection 
> creation
> which mentions faceting and so leads 

[jira] [Resolved] (SOLR-10749) Should ref guide asciidoc files' line length be limited?

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-10749.
---
Resolution: Won't Fix
  Assignee: Steve Rowe

> Should ref guide asciidoc files' line length be limited?
> 
>
> Key: SOLR-10749
> URL: https://issues.apache.org/jira/browse/SOLR-10749
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
>
> From [~dsmiley] and [~janhoy] on SOLR-10290:
> {quote}
> David: Can we auto-linewrap the asciidoc content we've imported somehow? The 
> lines are super-long in my IDE (IntelliJ). I can toggle the active editor's 
> "soft wrap" at least (View menu, then Active Editor menu).
> Jan: Yea, those lines are long
> {quote}
> From a conversation [~ctargett] and I had on SOLR-10379:
> {quote}
> Steve: I updated the ref guide docs. While I was at it, I installed and used 
> the IntelliJ plugin named "Wrap To Column" to wrap at 120 chars (a.k.a. "fill 
> paragraph") in the two .adoc files I edited.
> Cassandra: What is the point of this, or even, the big deal about asking your 
> IDE to do soft wraps instead?
> Steve: Not all editors support soft-wrapping. There is project consensus to 
> wrap code at 120-chars; why make an exception for these doc files?
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release 7.0 process starts

[Anshum Gupta]

Joel, I was actually asking if you meant removing the following section:

Being a major release, Solr 7 removes many deprecated APIs, changes various 
parameter defaults and
behavior. Some changes may require a re-index of your content. You are thus 
encouraged to thoroughly
read the "Upgrade Notes" at 
http://lucene.apache.org/solr/7_0_0/changes/Changes.html or in the
CHANGES.txt file accompanying the release.

Uwe: I am ready with all my (website) changes, and just waiting on the Solr 
‘news’ section that is a subset of the release notes. From the looks of it, we 
are done with the changes, and I can copy the relevant sections and commit the 
website changes. So yes, the release would happen on the 20th :)

-Anshum



> On Sep 20, 2017, at 8:34 AM, Joel Bernstein  wrote:
> 
> I think the release highlights are about what's exciting in the release. So 
> leading with the most exciting features is the way to go. Informing people of 
> changes that will affect them can be done in the upgrade notes in CHANGES.txt.
> 
> What do other people think about this?
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 11:21 AM, Anshum Gupta  > wrote:
> Also, I think it might make sense to add a line saying that the Ref Guide for 
> 7.0 would be released soon.
> 
> -Anshum
> 
> 
> 
>> On Sep 20, 2017, at 8:20 AM, Anshum Gupta > > wrote:
>> 
>> Sounds good.
>> 
>> Also, I am not a java expert like Uwe, and a few others here so let me know 
>> if we should leave in the ‘Jigsaw’ part.
>> 
>> David, you added that yesterday and Mike looked at the Lucene release notes 
>> and let it stay there. So I was wondering if it’s important/reasonable 
>> enough to highlight in the release notes.
>> 
>> -Anshum
>> 
>> 
>> 
>>> On Sep 20, 2017, at 8:12 AM, Joel Bernstein >> > wrote:
>>> 
>>> I would also consider changing the order of the list to highlight the most 
>>> interesting features.
>>> 
>>> If I saw this as the top highlight I would think of this is mainly a 
>>> maintenance release. 
>>> 
>>> 
>>> Indented JSON is now the default response format for all APIs,
>>>   pass wt=json and/or indent=off to use the previous unindented XML format.
>>> 
>>> 
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ 
>>> 
>>> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein >> > wrote:
>>> I just made the edit.
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ 
>>> 
>>> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein >> > wrote:
>>> For streaming expressions let's go with:
>>> 
>>> Solr 7 Streaming Expressions adds a new statistical programming syntax for
>>> the statistical analysis of sql queries, random samples, time series and
>>> graph result sets.
>>> 
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ 
>>> 
>>> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
>>> > wrote:
>>> Cool. How about 7th and 8th bullet points like this. 8th bullet ending in 
>>> Java 9 future magic still, not that the magic counts but fitting things on 
>>> roughly a screen full for folks to easily get the gist of the new release 
>>> is important I think.
>>> 
>>> -Christine
>>> 
>>> * Solr 7 adds Streaming Expressions, a new statistical programming syntax 
>>> for
>>>   the statistical analysis of sql queries, random samples, time series and
>>>   graph result sets.
>>> 
>>> * Solr 7 is tested with and verified to support Java 9
>>> 
>>> From: dev@lucene.apache.org  At: 09/20/17 
>>> 15:54:54
>>> To:  Christine Poerschke (BLOOMBERG/ LONDON )  
>>> ,  dev@lucene.apache.org 
>>> 
>>> 
>>> Subject: Re: Release 7.0 process starts
>>> This looks good, other than the wt=xml correction in #1, as Varun pointed 
>>> out. Also, I really think we should highlight streaming expressions (Math 
>>> Engine) even if that means we don’t hit the ‘7 points’ mark :).
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
 On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
 > wrote:
 
 Totally agree with choosing _7_ highlights for the Solr _7_ release!
 
 Below is the revised draft I came up with:
 
 (Notice that v2 is the 2nd bullet, though I think it yet needs to mention 
 one or _two_ benefits of using the new API especially since we mention 
 that /solr/ continues to work.)
 
 (Also notice some re-ordering of the bullets starting with the 
 used-by-many JSON first, 

Re: Release 7.0 process starts

[Joel Bernstein]

I'm happy to include Java 9.0 in the release highlights.

Anshum, is that what you were asking about? (Do you mean to remove the note
about upgrading completely)

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 12:16 PM, Uwe Schindler  wrote:

> Hi,
>
>
>
> the reason to mention it is mainly: Java 9 comes out tomorrow! So it’s
> important in that sense. The Java world is looking at the release of Java 9
> tomorrow, so if we have our own release at the start – just in time, I’d
> make the link explicit. So I’d also hurry up with the release so it comes
> out today and not tomorrow, Sept 21.
>
>
>
> On top of this, upgrading to Java 9 is recommended, because there should
> be significant speed improvements when using MMapDircetory (default) and
> DocValues (as it eliminates lots of bounds checks during optimization). Of
> course, this depends on your usage of Solr/Lucene.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19
> , D-28357
> Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* ansh...@apple.com [mailto:ansh...@apple.com]
> *Sent:* Wednesday, September 20, 2017 5:20 PM
>
> *To:* dev@lucene.apache.org
> *Subject:* Re: Release 7.0 process starts
>
>
>
> Sounds good.
>
>
>
> Also, I am not a java expert like Uwe, and a few others here so let me
> know if we should leave in the ‘Jigsaw’ part.
>
>
>
> David, you added that yesterday and Mike looked at the Lucene release
> notes and let it stay there. So I was wondering if it’s
> important/reasonable enough to highlight in the release notes.
>
>
>
> -Anshum
>
>
>
>
>
>
>
> On Sep 20, 2017, at 8:12 AM, Joel Bernstein  wrote:
>
>
>
> I would also consider changing the order of the list to highlight the most
> interesting features.
>
>
>
> If I saw this as the top highlight I would think of this is mainly a
> maintenance release.
>
>
>
>
>
> Indented JSON is now the default response format for all APIs,
>
>   pass wt=json and/or indent=off to use the previous unindented XML format.
>
>
>
>
>
>
> Joel Bernstein
>
> http://joelsolr.blogspot.com/
>
>
>
> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein 
> wrote:
>
> I just made the edit.
>
>
> Joel Bernstein
>
> http://joelsolr.blogspot.com/
>
>
>
> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein 
> wrote:
>
> For streaming expressions let's go with:
>
>
>
> Solr 7 Streaming Expressions adds a new statistical programming syntax for
>
> the statistical analysis of sql queries, random samples, time series and
>
> graph result sets.
>
>
>
>
> Joel Bernstein
>
> http://joelsolr.blogspot.com/
>
>
>
> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
> Cool. How about 7th and 8th bullet points like this. 8th bullet ending in
> Java 9 future magic still, not that the magic counts but fitting things on
> roughly a screen full for folks to easily get the gist of the new release
> is important I think.
>
>
>
> -Christine
>
>
>
> * Solr 7 adds Streaming Expressions, a new statistical programming syntax
> for
>
> the statistical analysis of sql queries, random samples, time series and
>
> graph result sets.
>
>
>
> * Solr 7 is tested with and verified to support Java 9
>
>
>
> From: dev@lucene.apache.org At: 09/20/17 15:54:54
>
> To: Christine Poerschke (BLOOMBERG/ LONDON ) ,
> dev@lucene.apache.org
>
>
> Subject: Re: Release 7.0 process starts
>
> This looks good, other than the wt=xml correction in #1, as Varun pointed
> out. Also, I really think we should highlight streaming expressions (Math
> Engine) even if that means we don’t hit the ‘7 points’ mark :).
>
>
>
> -Anshum
>
>
>
>
>
>
>
> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
>
>
> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>
>
>
> Below is the revised draft I came up with:
>
>
>
> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention
> one or _two_ benefits of using the new API especially since we mention that
> /solr/ continues to work.)
>
>
>
> (Also notice some re-ordering of the bullets starting with the
> used-by-many JSON first, then v2 API second, then third collection creation
> which mentions faceting and so leads over to the fourth bullet re: facet
> refinement. Fifth is the new replica types (that bullet being slightly
> longer than the others to explain what the types are about). Sixth is
> auto-scaling which mentions future releases (would folks use new replica
> types first before moving on to auto-scaling?). Seventh and last then is
> Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)
>
>
>
> *Solr 7.0 Release Highlights:*
>
>
>
> * Indented JSON is now the default response format for all APIs,
>
> pass wt=json and/or indent=off to use the 

RE: Release 7.0 process starts

[Uwe Schindler]

Hi,

 

the reason to mention it is mainly: Java 9 comes out tomorrow! So it’s 
important in that sense. The Java world is looking at the release of Java 9 
tomorrow, so if we have our own release at the start – just in time, I’d make 
the link explicit. So I’d also hurry up with the release so it comes out today 
and not tomorrow, Sept 21.

 

On top of this, upgrading to Java 9 is recommended, because there should be 
significant speed improvements when using MMapDircetory (default) and DocValues 
(as it eliminates lots of bounds checks during optimization). Of course, this 
depends on your usage of Solr/Lucene.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: ansh...@apple.com [mailto:ansh...@apple.com] 
Sent: Wednesday, September 20, 2017 5:20 PM
To: dev@lucene.apache.org
Subject: Re: Release 7.0 process starts

 

Sounds good.

 

Also, I am not a java expert like Uwe, and a few others here so let me know if 
we should leave in the ‘Jigsaw’ part.

 

David, you added that yesterday and Mike looked at the Lucene release notes and 
let it stay there. So I was wondering if it’s important/reasonable enough to 
highlight in the release notes.

 

-Anshum

 

 

 

On Sep 20, 2017, at 8:12 AM, Joel Bernstein  > wrote:

 

I would also consider changing the order of the list to highlight the most 
interesting features.

 

If I saw this as the top highlight I would think of this is mainly a 
maintenance release. 

 

 

Indented JSON is now the default response format for all APIs,
  pass wt=json and/or indent=off to use the previous unindented XML format.

 

 




Joel Bernstein

http://joelsolr.blogspot.com/

 

On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein  > wrote:

I just made the edit.




Joel Bernstein

http://joelsolr.blogspot.com/

 

On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein  > wrote:

For streaming expressions let's go with:

 

Solr 7 Streaming Expressions adds a new statistical programming syntax for

the statistical analysis of sql queries, random samples, time series and

graph result sets.

 




Joel Bernstein

http://joelsolr.blogspot.com/

 

On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
 > wrote:

Cool. How about 7th and 8th bullet points like this. 8th bullet ending in Java 
9 future magic still, not that the magic counts but fitting things on roughly a 
screen full for folks to easily get the gist of the new release is important I 
think.

 

-Christine

 

* Solr 7 adds Streaming Expressions, a new statistical programming syntax for

the statistical analysis of sql queries, random samples, time series and

graph result sets.

 

* Solr 7 is tested with and verified to support Java 9

 

From: dev@lucene.apache.org   At: 09/20/17 
15:54:54

To: Christine Poerschke (BLOOMBERG/ LONDON )   
, dev@lucene.apache.org  


Subject: Re: Release 7.0 process starts

This looks good, other than the wt=xml correction in #1, as Varun pointed out. 
Also, I really think we should highlight streaming expressions (Math Engine) 
even if that means we don’t hit the ‘7 points’ mark :).

 

-Anshum

 

 

 

On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
 > wrote:

 

Totally agree with choosing _7_ highlights for the Solr _7_ release!

 

Below is the revised draft I came up with:

 

(Notice that v2 is the 2nd bullet, though I think it yet needs to mention one 
or _two_ benefits of using the new API especially since we mention that /solr/ 
continues to work.)

 

(Also notice some re-ordering of the bullets starting with the used-by-many 
JSON first, then v2 API second, then third collection creation which mentions 
faceting and so leads over to the fourth bullet re: facet refinement. Fifth is 
the new replica types (that bullet being slightly longer than the others to 
explain what the types are about). Sixth is auto-scaling which mentions future 
releases (would folks use new replica types first before moving on to 
auto-scaling?). Seventh and last then is Solr _7_ mention with Java _9_ i.e. 
the just-arrived future again there.)

 

Solr 7.0 Release Highlights:

 

* Indented JSON is now the default response format for all APIs,

pass wt=json and/or indent=off to use the previous unindented XML format.

 

* The new v2 API, exposed at /api/ and also supported via SolrJ, is now the

preferred API, but /solr/ continues to work.

 

* A new `_default` configset is used if no config is specified at collection

creation. The data-driven functionality of this configset indexes strings as

analyzed 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-9-ea+181) - Build # 446 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/446/
Java: 64bit/jdk-9-ea+181 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.update.TestInPlaceUpdatesDistrib.test

Error Message:
inplace_updatable_float didn't match for replica at client: 
http://127.0.0.1:37709/collection1 expected:<112.0> but was:<1.0>

Stack Trace:
java.lang.AssertionError: inplace_updatable_float didn't match for replica at 
client: http://127.0.0.1:37709/collection1 expected:<112.0> but was:<1.0>
at 
__randomizedtesting.SeedInfo.seed([F91469ABADDA76F9:7140567103261B01]: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.apache.solr.update.TestInPlaceUpdatesDistrib.assertReplicaValue(TestInPlaceUpdatesDistrib.java:980)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.outOfOrderUpdatesIndividualReplicaTest(TestInPlaceUpdatesDistrib.java:643)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:144)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)

Re: Release 7.0 process starts

[Walter Underwood]

I scan it for all big changes, not just features. Is a version of Java dropped 
in this release? That sort of thing should be included.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Sep 20, 2017, at 9:12 AM, Anshum Gupta  wrote:
> 
> Do you mean to remove the note about upgrading completely? Currently it’s 
> just a pointer to the CHANGES and recommends users to go through it before 
> upgrading.
> 
> -Anshum
> 
> 
> 
>> On Sep 20, 2017, at 8:34 AM, Joel Bernstein > > wrote:
>> 
>> I think the release highlights are about what's exciting in the release. So 
>> leading with the most exciting features is the way to go. Informing people 
>> of changes that will affect them can be done in the upgrade notes in 
>> CHANGES.txt.
>> 
>> What do other people think about this?
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ 
>> 
>> On Wed, Sep 20, 2017 at 11:21 AM, Anshum Gupta > > wrote:
>> Also, I think it might make sense to add a line saying that the Ref Guide 
>> for 7.0 would be released soon.
>> 
>> -Anshum
>> 
>> 
>> 
>>> On Sep 20, 2017, at 8:20 AM, Anshum Gupta >> > wrote:
>>> 
>>> Sounds good.
>>> 
>>> Also, I am not a java expert like Uwe, and a few others here so let me know 
>>> if we should leave in the ‘Jigsaw’ part.
>>> 
>>> David, you added that yesterday and Mike looked at the Lucene release notes 
>>> and let it stay there. So I was wondering if it’s important/reasonable 
>>> enough to highlight in the release notes.
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
 On Sep 20, 2017, at 8:12 AM, Joel Bernstein > wrote:
 
 I would also consider changing the order of the list to highlight the most 
 interesting features.
 
 If I saw this as the top highlight I would think of this is mainly a 
 maintenance release. 
 
 
 Indented JSON is now the default response format for all APIs,
   pass wt=json and/or indent=off to use the previous unindented XML format.
 
 
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein > wrote:
 I just made the edit.
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein > wrote:
 For streaming expressions let's go with:
 
 Solr 7 Streaming Expressions adds a new statistical programming syntax for
 the statistical analysis of sql queries, random samples, time series and
 graph result sets.
 
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
 > wrote:
 Cool. How about 7th and 8th bullet points like this. 8th bullet ending in 
 Java 9 future magic still, not that the magic counts but fitting things on 
 roughly a screen full for folks to easily get the gist of the new release 
 is important I think.
 
 -Christine
 
 * Solr 7 adds Streaming Expressions, a new statistical programming syntax 
 for
   the statistical analysis of sql queries, random samples, time series and
   graph result sets.
 
 * Solr 7 is tested with and verified to support Java 9
 
 From: dev@lucene.apache.org  At: 09/20/17 
 15:54:54
 To:  Christine Poerschke (BLOOMBERG/ LONDON )  
 ,  dev@lucene.apache.org 
 
 
 Subject: Re: Release 7.0 process starts
 This looks good, other than the wt=xml correction in #1, as Varun pointed 
 out. Also, I really think we should highlight streaming expressions (Math 
 Engine) even if that means we don’t hit the ‘7 points’ mark :).
 
 -Anshum
 
 
 
> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
> > wrote:
> 
> Totally agree with choosing _7_ highlights for the Solr _7_ release!
> 
> Below is the revised draft I came up with:
> 
> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention 
> one or _two_ benefits of using the new API especially since we mention 
> that /solr/ continues to work.)
> 
> (Also notice some re-ordering of the bullets starting with the 
> used-by-many JSON first, then v2 API second, then third collection 
> creation which mentions faceting 

Re: Release 7.0 process starts

[Anshum Gupta]

Do you mean to remove the note about upgrading completely? Currently it’s just 
a pointer to the CHANGES and recommends users to go through it before upgrading.

-Anshum



> On Sep 20, 2017, at 8:34 AM, Joel Bernstein  wrote:
> 
> I think the release highlights are about what's exciting in the release. So 
> leading with the most exciting features is the way to go. Informing people of 
> changes that will affect them can be done in the upgrade notes in CHANGES.txt.
> 
> What do other people think about this?
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 11:21 AM, Anshum Gupta  > wrote:
> Also, I think it might make sense to add a line saying that the Ref Guide for 
> 7.0 would be released soon.
> 
> -Anshum
> 
> 
> 
>> On Sep 20, 2017, at 8:20 AM, Anshum Gupta > > wrote:
>> 
>> Sounds good.
>> 
>> Also, I am not a java expert like Uwe, and a few others here so let me know 
>> if we should leave in the ‘Jigsaw’ part.
>> 
>> David, you added that yesterday and Mike looked at the Lucene release notes 
>> and let it stay there. So I was wondering if it’s important/reasonable 
>> enough to highlight in the release notes.
>> 
>> -Anshum
>> 
>> 
>> 
>>> On Sep 20, 2017, at 8:12 AM, Joel Bernstein >> > wrote:
>>> 
>>> I would also consider changing the order of the list to highlight the most 
>>> interesting features.
>>> 
>>> If I saw this as the top highlight I would think of this is mainly a 
>>> maintenance release. 
>>> 
>>> 
>>> Indented JSON is now the default response format for all APIs,
>>>   pass wt=json and/or indent=off to use the previous unindented XML format.
>>> 
>>> 
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ 
>>> 
>>> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein >> > wrote:
>>> I just made the edit.
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ 
>>> 
>>> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein >> > wrote:
>>> For streaming expressions let's go with:
>>> 
>>> Solr 7 Streaming Expressions adds a new statistical programming syntax for
>>> the statistical analysis of sql queries, random samples, time series and
>>> graph result sets.
>>> 
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ 
>>> 
>>> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
>>> > wrote:
>>> Cool. How about 7th and 8th bullet points like this. 8th bullet ending in 
>>> Java 9 future magic still, not that the magic counts but fitting things on 
>>> roughly a screen full for folks to easily get the gist of the new release 
>>> is important I think.
>>> 
>>> -Christine
>>> 
>>> * Solr 7 adds Streaming Expressions, a new statistical programming syntax 
>>> for
>>>   the statistical analysis of sql queries, random samples, time series and
>>>   graph result sets.
>>> 
>>> * Solr 7 is tested with and verified to support Java 9
>>> 
>>> From: dev@lucene.apache.org  At: 09/20/17 
>>> 15:54:54
>>> To:  Christine Poerschke (BLOOMBERG/ LONDON )  
>>> ,  dev@lucene.apache.org 
>>> 
>>> 
>>> Subject: Re: Release 7.0 process starts
>>> This looks good, other than the wt=xml correction in #1, as Varun pointed 
>>> out. Also, I really think we should highlight streaming expressions (Math 
>>> Engine) even if that means we don’t hit the ‘7 points’ mark :).
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
 On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
 > wrote:
 
 Totally agree with choosing _7_ highlights for the Solr _7_ release!
 
 Below is the revised draft I came up with:
 
 (Notice that v2 is the 2nd bullet, though I think it yet needs to mention 
 one or _two_ benefits of using the new API especially since we mention 
 that /solr/ continues to work.)
 
 (Also notice some re-ordering of the bullets starting with the 
 used-by-many JSON first, then v2 API second, then third collection 
 creation which mentions faceting and so leads over to the fourth bullet 
 re: facet refinement. Fifth is the new replica types (that bullet being 
 slightly longer than the others to explain what the types are about). 
 Sixth is auto-scaling which mentions future releases (would folks use new 
 replica types first before moving on to auto-scaling?). Seventh and last 
 then is Solr _7_ mention with Java _9_ i.e. the just-arrived future again 
 there.)
 
 Solr 7.0 Release 

[jira] [Commented] (SOLR-9959) SolrInfoMBean-s category and hierarchy cleanup

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9959:
---

Commit 70bffbdf13af5c371d9afe6e9e4159864876af6c in lucene-solr's branch 
refs/heads/branch_7_0 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=70bffbd ]

SOLR-9959: Ref Guide changes for JMX and metric name changes


> SolrInfoMBean-s category and hierarchy cleanup
> --
>
> Key: SOLR-9959
> URL: https://issues.apache.org/jira/browse/SOLR-9959
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.0
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-9959.patch, SOLR-9959.patch, SOLR-9959.patch
>
>
> SOLR-9947 changed categories of some of {{SolrInfoMBean-s}}, and it also 
> added an alternative view in JMX, similar to the one produced by 
> {{SolrJmxReporter}}.
> Some changes were left out from that issue because they would break the 
> back-compatibility in 6.x, but they should be done before 7.0:
> * remove the old JMX view of {{SolrInfoMBean}}-s and improve the new one so 
> that it's more readable and useful.
> * in many cases {{SolrInfoMBean.getName()}} just returns a FQCN, but it could 
> be more informative - eg. for highlighter or query plugins this could be the 
> symbolic name of a plugin that users know and use in configuration.
> * top-level categories need more thought. On one hand it's best to minimize 
> their number, on the other hand they need to meaningfully represent the 
> functionality of components that use them. SOLR-9947 made some cosmetic 
> changes, but more discussion is necessary (eg. QUERY vs. SEARCHHANDLER)
> * we should consider removing some of the methods in {{SolrInfoMBean}} that 
> usually don't return any useful information, eg. {{getDocs}}, {{getSource()}} 
> and {{getVersion()}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9959) SolrInfoMBean-s category and hierarchy cleanup

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9959:
---

Commit 839cb9081cbcda171dd872b5c271d8e2ec72081a in lucene-solr's branch 
refs/heads/branch_7x from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=839cb90 ]

SOLR-9959: Ref Guide changes for JMX and metric name changes


> SolrInfoMBean-s category and hierarchy cleanup
> --
>
> Key: SOLR-9959
> URL: https://issues.apache.org/jira/browse/SOLR-9959
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.0
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-9959.patch, SOLR-9959.patch, SOLR-9959.patch
>
>
> SOLR-9947 changed categories of some of {{SolrInfoMBean-s}}, and it also 
> added an alternative view in JMX, similar to the one produced by 
> {{SolrJmxReporter}}.
> Some changes were left out from that issue because they would break the 
> back-compatibility in 6.x, but they should be done before 7.0:
> * remove the old JMX view of {{SolrInfoMBean}}-s and improve the new one so 
> that it's more readable and useful.
> * in many cases {{SolrInfoMBean.getName()}} just returns a FQCN, but it could 
> be more informative - eg. for highlighter or query plugins this could be the 
> symbolic name of a plugin that users know and use in configuration.
> * top-level categories need more thought. On one hand it's best to minimize 
> their number, on the other hand they need to meaningfully represent the 
> functionality of components that use them. SOLR-9947 made some cosmetic 
> changes, but more discussion is necessary (eg. QUERY vs. SEARCHHANDLER)
> * we should consider removing some of the methods in {{SolrInfoMBean}} that 
> usually don't return any useful information, eg. {{getDocs}}, {{getSource()}} 
> and {{getVersion()}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9959) SolrInfoMBean-s category and hierarchy cleanup

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9959:
---

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

SOLR-9959: Ref Guide changes for JMX and metric name changes


> SolrInfoMBean-s category and hierarchy cleanup
> --
>
> Key: SOLR-9959
> URL: https://issues.apache.org/jira/browse/SOLR-9959
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.0
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-9959.patch, SOLR-9959.patch, SOLR-9959.patch
>
>
> SOLR-9947 changed categories of some of {{SolrInfoMBean-s}}, and it also 
> added an alternative view in JMX, similar to the one produced by 
> {{SolrJmxReporter}}.
> Some changes were left out from that issue because they would break the 
> back-compatibility in 6.x, but they should be done before 7.0:
> * remove the old JMX view of {{SolrInfoMBean}}-s and improve the new one so 
> that it's more readable and useful.
> * in many cases {{SolrInfoMBean.getName()}} just returns a FQCN, but it could 
> be more informative - eg. for highlighter or query plugins this could be the 
> symbolic name of a plugin that users know and use in configuration.
> * top-level categories need more thought. On one hand it's best to minimize 
> their number, on the other hand they need to meaningfully represent the 
> functionality of components that use them. SOLR-9947 made some cosmetic 
> changes, but more discussion is necessary (eg. QUERY vs. SEARCHHANDLER)
> * we should consider removing some of the methods in {{SolrInfoMBean}} that 
> usually don't return any useful information, eg. {{getDocs}}, {{getSource()}} 
> and {{getVersion()}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7973) Update dictionary version for Ukrainian analyzer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7973:


GitHub user arysin opened a pull request:

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

LUCENE-7973: Update dictionary version for Ukrainian analyzer



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

$ git pull https://github.com/arysin/lucene-solr branch_7x

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

https://github.com/apache/lucene-solr/pull/251.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 #251


commit 01e89a2491948d780e78d8b10387413a8fa46352
Author: Andriy Rysin 
Date:   2017-09-20T15:30:23Z

LUCENE-7973: Update dictionary version for Ukrainian analyzer




> Update dictionary version for Ukrainian analyzer
> 
>
> Key: LUCENE-7973
> URL: https://issues.apache.org/jira/browse/LUCENE-7973
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>
> Update morfologik dictionary version to 3.9.0 for Ukrainian analyzer.
> There's 60K of new lemmas there along with some other improvements and fixes, 
> particularly Ukrainian town names have been synchronized with official 
> standard.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7973) Update dictionary version for Ukrainian analyzer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7973:


GitHub user arysin opened a pull request:

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

LUCENE-7973: Update dictionary version for Ukrainian analyzer



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

$ git pull https://github.com/arysin/lucene-solr branch_7_0

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

https://github.com/apache/lucene-solr/pull/252.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 #252


commit 0544503f0eed616476988bfaef1fe60326a62965
Author: Andriy Rysin 
Date:   2017-09-20T15:30:23Z

LUCENE-7973: Update dictionary version for Ukrainian analyzer




> Update dictionary version for Ukrainian analyzer
> 
>
> Key: LUCENE-7973
> URL: https://issues.apache.org/jira/browse/LUCENE-7973
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>
> Update morfologik dictionary version to 3.9.0 for Ukrainian analyzer.
> There's 60K of new lemmas there along with some other improvements and fixes, 
> particularly Ukrainian town names have been synchronized with official 
> standard.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7973) Update dictionary version for Ukrainian analyzer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7973:


GitHub user arysin opened a pull request:

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

LUCENE-7973: Update dictionary version for Ukrainian analyzer



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

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

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

https://github.com/apache/lucene-solr/pull/250.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 #250


commit 07c114275649df95ee64ab7c6f14318fbbd644c2
Author: Andriy Rysin 
Date:   2017-09-20T15:30:23Z

LUCENE-7973: Update dictionary version for Ukrainian analyzer




> Update dictionary version for Ukrainian analyzer
> 
>
> Key: LUCENE-7973
> URL: https://issues.apache.org/jira/browse/LUCENE-7973
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>
> Update morfologik dictionary version to 3.9.0 for Ukrainian analyzer.
> There's 60K of new lemmas there along with some other improvements and fixes, 
> particularly Ukrainian town names have been synchronized with official 
> standard.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #252: LUCENE-7973: Update dictionary version for Uk...

[arysin]

GitHub user arysin opened a pull request:

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

LUCENE-7973: Update dictionary version for Ukrainian analyzer



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

$ git pull https://github.com/arysin/lucene-solr branch_7_0

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

https://github.com/apache/lucene-solr/pull/252.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 #252


commit 0544503f0eed616476988bfaef1fe60326a62965
Author: Andriy Rysin 
Date:   2017-09-20T15:30:23Z

LUCENE-7973: Update dictionary version for Ukrainian analyzer




---

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

[GitHub] lucene-solr pull request #251: LUCENE-7973: Update dictionary version for Uk...

[arysin]

GitHub user arysin opened a pull request:

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

LUCENE-7973: Update dictionary version for Ukrainian analyzer



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

$ git pull https://github.com/arysin/lucene-solr branch_7x

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

https://github.com/apache/lucene-solr/pull/251.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 #251


commit 01e89a2491948d780e78d8b10387413a8fa46352
Author: Andriy Rysin 
Date:   2017-09-20T15:30:23Z

LUCENE-7973: Update dictionary version for Ukrainian analyzer




---

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

[GitHub] lucene-solr pull request #250: LUCENE-7973: Update dictionary version for Uk...

[arysin]

GitHub user arysin opened a pull request:

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

LUCENE-7973: Update dictionary version for Ukrainian analyzer



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

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

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

https://github.com/apache/lucene-solr/pull/250.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 #250


commit 07c114275649df95ee64ab7c6f14318fbbd644c2
Author: Andriy Rysin 
Date:   2017-09-20T15:30:23Z

LUCENE-7973: Update dictionary version for Ukrainian analyzer




---

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

Re: Release 7.0 process starts

[Joel Bernstein]

I think the release highlights are about what's exciting in the release. So
leading with the most exciting features is the way to go. Informing people
of changes that will affect them can be done in the upgrade notes in
CHANGES.txt.

What do other people think about this?

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 11:21 AM, Anshum Gupta  wrote:

> Also, I think it might make sense to add a line saying that the Ref Guide
> for 7.0 would be released soon.
>
> -Anshum
>
>
>
> On Sep 20, 2017, at 8:20 AM, Anshum Gupta  wrote:
>
> Sounds good.
>
> Also, I am not a java expert like Uwe, and a few others here so let me
> know if we should leave in the ‘Jigsaw’ part.
>
> David, you added that yesterday and Mike looked at the Lucene release
> notes and let it stay there. So I was wondering if it’s
> important/reasonable enough to highlight in the release notes.
>
> -Anshum
>
>
>
> On Sep 20, 2017, at 8:12 AM, Joel Bernstein  wrote:
>
> I would also consider changing the order of the list to highlight the most
> interesting features.
>
> If I saw this as the top highlight I would think of this is mainly a
> maintenance release.
>
>
> Indented JSON is now the default response format for all APIs,  pass wt=json 
> and/or indent=off to use the previous unindented XML format.
>
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein 
> wrote:
>
>> I just made the edit.
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein 
>> wrote:
>>
>>> For streaming expressions let's go with:
>>>
>>> Solr 7 Streaming Expressions adds a new statistical programming syntax
>>> for
>>> the statistical analysis of sql queries, random samples, time series and
>>> graph result sets.
>>>
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/
>>> LONDON)  wrote:
>>>
 Cool. How about 7th and 8th bullet points like this. 8th bullet ending
 in Java 9 future magic still, not that the magic counts but fitting things
 on roughly a screen full for folks to easily get the gist of the new
 release is important I think.

 -Christine

 * Solr 7 adds Streaming Expressions, a new statistical programming
 syntax for
 the statistical analysis of sql queries, random samples, time series and
 graph result sets.

 * Solr 7 is tested with and verified to support Java 9

 From: dev@lucene.apache.org At: 09/20/17 15:54:54
 To: Christine Poerschke (BLOOMBERG/ LONDON ) ,
 dev@lucene.apache.org

 Subject: Re: Release 7.0 process starts

 This looks good, other than the wt=xml correction in #1, as Varun
 pointed out. Also, I really think we should highlight streaming expressions
 (Math Engine) even if that means we don’t hit the ‘7 points’ mark :).

 -Anshum



 On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
 cpoersc...@bloomberg.net> wrote:

 Totally agree with choosing _7_ highlights for the Solr _7_ release!

 Below is the revised draft I came up with:

 (Notice that v2 is the 2nd bullet, though I think it yet needs to
 mention one or _two_ benefits of using the new API especially since we
 mention that /solr/ continues to work.)

 (Also notice some re-ordering of the bullets starting with the
 used-by-many JSON first, then v2 API second, then third collection creation
 which mentions faceting and so leads over to the fourth bullet re: facet
 refinement. Fifth is the new replica types (that bullet being slightly
 longer than the others to explain what the types are about). Sixth is
 auto-scaling which mentions future releases (would folks use new replica
 types first before moving on to auto-scaling?). Seventh and last then is
 Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)

 Solr 7.0 Release Highlights:

 * Indented JSON is now the default response format for all APIs,
 pass wt=json and/or indent=off to use the previous unindented XML
 format.

 * The new v2 API, exposed at /api/ and also supported via SolrJ, is now
 the
 preferred API, but /solr/ continues to work.

 * A new `_default` configset is used if no config is specified at
 collection
 creation. The data-driven functionality of this configset indexes
 strings as
 analyzed text while at the same time copying to a `*_str` field
 suitable for
 faceting.

 * The JSON Facet API now supports two-phase facet refinement to ensure
 accurate
 counts and statistics for facet buckets returned in distributed mode.

 * Replica Types 

[jira] [Closed] (SOLR-7576) Implement RequestHandler in Javascript

[Noble Paul (JIRA)]

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

Noble Paul closed SOLR-7576.

Resolution: Won't Fix

it's a security nightmare

> Implement RequestHandler in Javascript
> --
>
> Key: SOLR-7576
> URL: https://issues.apache.org/jira/browse/SOLR-7576
> Project: Solr
>  Issue Type: New Feature
>Reporter: Noble Paul
> Attachments: SOLR-7576.patch, SOLR-7576.patch
>
>
> Solr now support dynamic loading (SOLR-7073) of components and it is secured 
> in SOLR-7126
> We can extend the same functionality with JS as well
> the handler {{/js}} is implicitly registered
> To make this work
> * Solr should be started with {{-Denable.js.loading=true}}
> * The javascript must be loaded to the {{.system}} collection using the blob 
> store API
> * Sign the javascript and pass the signature in a param called {{_sig}}
> The {{JSRequestHandler}} is implicitly defined and it can be accessed by 
> hitting {{/js//}} 
> Steps for developing scripts
> # start the cluster with the {{enable.js.loading}} . If you are starting 
> using our script it would be {{bin/solr start -e cloud -a 
> "-Denable.js.loading=true"}} . You would not need security during development 
> , so don't add the private keys to Solr
> # create {{.system}} collection {{bin/solr create -c .system}}
> # Write your javascript code . (say {{test.js}} )
> # post it to {{.system}} collection . {{curl -X POST -H 'Content-Type: 
> application/octet-stream' --data-binary @test.js 
> http://localhost:8983/solr/.system/blob/test}}
> # run your script {{http://host:8983/solr/gettingstarted/js/test/1}}
> # Edit your script and repeat from step #4 . Keep in mind that the version 
> would be bumped up every time you post a new script . So, the second time the 
> url would be {{http://host:8983/solr/gettingstarted/js/test/2}} . So on and 
> so forth
> sample programs
> 1) writes a val to output
> {code:javascript}
> //empty line
> $.response().add('testkey','Test Val');
> {code}
> 2)  manipulate the output to add an extra field to each doc 
> {code}
> //empty line
> var l = [];
> $.query({
>   q: '*:*',
>   qt: '/select',
>   start:0,
>   }).forEach('response', function(doc) {
>  doc.put('script', 'Added this 
> value');
>  l.push(doc);
>   });
>  $.response().add('alldocs', l);
> {code}
> 3)  stream through all the docs
> {code:Javascript}
> //empty line
> $.query({
>   q: '*:*',
>   qt: '/select',
>   start:0,
>   distrib:'false'
>   }).pipe('response', 'docs', function(doc) { // the pipe function is 
> executed right before the response writer and right after the transformers   
>  if('IT'== doc.get('genre_s')) return 
> null;
>  doc.put('script', 'Added this 
> value');
>  return doc;
>   });
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11380) UpdateRequest.setDocIterator() does not actually stream the docs

[Noble Paul (JIRA)]

Noble Paul created SOLR-11380:
-

 Summary: UpdateRequest.setDocIterator() does not actually stream 
the docs
 Key: SOLR-11380
 URL: https://issues.apache.org/jira/browse/SOLR-11380
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11380) UpdateRequest.setDocIterator() does not actually stream the docs

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11380:
---

It just buffers all the docs in memory and upload it in one single request

> UpdateRequest.setDocIterator() does not actually stream the docs
> 
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release 7.0 process starts

[Anshum Gupta]

Also, I think it might make sense to add a line saying that the Ref Guide for 
7.0 would be released soon.

-Anshum



> On Sep 20, 2017, at 8:20 AM, Anshum Gupta  wrote:
> 
> Sounds good.
> 
> Also, I am not a java expert like Uwe, and a few others here so let me know 
> if we should leave in the ‘Jigsaw’ part.
> 
> David, you added that yesterday and Mike looked at the Lucene release notes 
> and let it stay there. So I was wondering if it’s important/reasonable enough 
> to highlight in the release notes.
> 
> -Anshum
> 
> 
> 
>> On Sep 20, 2017, at 8:12 AM, Joel Bernstein > > wrote:
>> 
>> I would also consider changing the order of the list to highlight the most 
>> interesting features.
>> 
>> If I saw this as the top highlight I would think of this is mainly a 
>> maintenance release. 
>> 
>> 
>> Indented JSON is now the default response format for all APIs,
>>   pass wt=json and/or indent=off to use the previous unindented XML format.
>> 
>> 
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ 
>> 
>> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein > > wrote:
>> I just made the edit.
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ 
>> 
>> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein > > wrote:
>> For streaming expressions let's go with:
>> 
>> Solr 7 Streaming Expressions adds a new statistical programming syntax for
>> the statistical analysis of sql queries, random samples, time series and
>> graph result sets.
>> 
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ 
>> 
>> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
>> > wrote:
>> Cool. How about 7th and 8th bullet points like this. 8th bullet ending in 
>> Java 9 future magic still, not that the magic counts but fitting things on 
>> roughly a screen full for folks to easily get the gist of the new release is 
>> important I think.
>> 
>> -Christine
>> 
>> * Solr 7 adds Streaming Expressions, a new statistical programming syntax for
>>   the statistical analysis of sql queries, random samples, time series and
>>   graph result sets.
>> 
>> * Solr 7 is tested with and verified to support Java 9
>> 
>> From: dev@lucene.apache.org  At: 09/20/17 
>> 15:54:54
>> To:  Christine Poerschke (BLOOMBERG/ LONDON )  
>> ,  dev@lucene.apache.org 
>> 
>> 
>> Subject: Re: Release 7.0 process starts
>> This looks good, other than the wt=xml correction in #1, as Varun pointed 
>> out. Also, I really think we should highlight streaming expressions (Math 
>> Engine) even if that means we don’t hit the ‘7 points’ mark :).
>> 
>> -Anshum
>> 
>> 
>> 
>>> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
>>> > wrote:
>>> 
>>> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>>> 
>>> Below is the revised draft I came up with:
>>> 
>>> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention 
>>> one or _two_ benefits of using the new API especially since we mention that 
>>> /solr/ continues to work.)
>>> 
>>> (Also notice some re-ordering of the bullets starting with the used-by-many 
>>> JSON first, then v2 API second, then third collection creation which 
>>> mentions faceting and so leads over to the fourth bullet re: facet 
>>> refinement. Fifth is the new replica types (that bullet being slightly 
>>> longer than the others to explain what the types are about). Sixth is 
>>> auto-scaling which mentions future releases (would folks use new replica 
>>> types first before moving on to auto-scaling?). Seventh and last then is 
>>> Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)
>>> 
>>> Solr 7.0 Release Highlights:
>>> 
>>> * Indented JSON is now the default response format for all APIs,
>>>   pass wt=json and/or indent=off to use the previous unindented XML format.
>>> 
>>> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
>>>   preferred API, but /solr/ continues to work.
>>> 
>>> * A new `_default` configset is used if no config is specified at collection
>>>   creation. The data-driven functionality of this configset indexes strings 
>>> as
>>>   analyzed text while at the same time copying to a `*_str` field suitable 
>>> for
>>>   faceting.
>>> 
>>> * The JSON Facet API now supports two-phase facet refinement to ensure 
>>> accurate
>>>   counts and statistics for facet buckets returned in distributed mode.
>>> 
>>> * Replica Types - Solr 7 supports different replica types, which handle 
>>> updates
>>>   differently. In addition to pure NRT 

Re: Release 7.0 process starts

[Joel Bernstein]

This is how I would list things:

* Replica Types - Solr 7 supports different replica types, which
handle updates  differently. In addition to pure NRT operation where
all replicas build an  index and keep a replication log, you can now
also add so called PULL  replicas, achieving the read-speed optimized
benefits of a master/slave  setup while at the same time keeping index
redundancy.* Auto-scaling. Solr can now allocate new replicas to nodes
using a new auto  scaling policy framework. This framework will in
future releases enable Solr  to move shards around based on load, disk
etc.

* The JSON Facet API now supports two-phase facet refinement to ensure
accurate  counts and statistics for facet buckets returned in
distributed mode.
* Streaming Expressions adds a new statistical programming syntax for
the statistical analysis of sql queries, random samples, time series
and  graph result sets.

* Analytics Component2 Note

* The new v2 API, exposed at /api/ and also supported via SolrJ, is
now the preferred
API, but /solr/ continues to work.

* Indented JSON is now the default response format for all APIs,  pass
wt=json and/or indent=off to use the previous unindented XML format.





Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 11:12 AM, Joel Bernstein  wrote:

> I would also consider changing the order of the list to highlight the most
> interesting features.
>
> If I saw this as the top highlight I would think of this is mainly a
> maintenance release.
>
>
> Indented JSON is now the default response format for all APIs,  pass wt=json 
> and/or indent=off to use the previous unindented XML format.
>
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein 
> wrote:
>
>> I just made the edit.
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein 
>> wrote:
>>
>>> For streaming expressions let's go with:
>>>
>>> Solr 7 Streaming Expressions adds a new statistical programming syntax
>>> for
>>> the statistical analysis of sql queries, random samples, time series and
>>> graph result sets.
>>>
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/
>>> LONDON)  wrote:
>>>
 Cool. How about 7th and 8th bullet points like this. 8th bullet ending
 in Java 9 future magic still, not that the magic counts but fitting things
 on roughly a screen full for folks to easily get the gist of the new
 release is important I think.

 -Christine

 * Solr 7 adds Streaming Expressions, a new statistical programming
 syntax for
 the statistical analysis of sql queries, random samples, time series and
 graph result sets.

 * Solr 7 is tested with and verified to support Java 9

 From: dev@lucene.apache.org At: 09/20/17 15:54:54
 To: Christine Poerschke (BLOOMBERG/ LONDON ) ,
 dev@lucene.apache.org

 Subject: Re: Release 7.0 process starts

 This looks good, other than the wt=xml correction in #1, as Varun
 pointed out. Also, I really think we should highlight streaming expressions
 (Math Engine) even if that means we don’t hit the ‘7 points’ mark :).

 -Anshum



 On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
 cpoersc...@bloomberg.net> wrote:

 Totally agree with choosing _7_ highlights for the Solr _7_ release!

 Below is the revised draft I came up with:

 (Notice that v2 is the 2nd bullet, though I think it yet needs to
 mention one or _two_ benefits of using the new API especially since we
 mention that /solr/ continues to work.)

 (Also notice some re-ordering of the bullets starting with the
 used-by-many JSON first, then v2 API second, then third collection creation
 which mentions faceting and so leads over to the fourth bullet re: facet
 refinement. Fifth is the new replica types (that bullet being slightly
 longer than the others to explain what the types are about). Sixth is
 auto-scaling which mentions future releases (would folks use new replica
 types first before moving on to auto-scaling?). Seventh and last then is
 Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)

 Solr 7.0 Release Highlights:

 * Indented JSON is now the default response format for all APIs,
 pass wt=json and/or indent=off to use the previous unindented XML
 format.

 * The new v2 API, exposed at /api/ and also supported via SolrJ, is now
 the
 preferred API, but /solr/ continues to work.

 * A new `_default` configset is used if no config is specified at
 collection
 creation. The data-driven functionality of this configset indexes
 

Re: Release 7.0 process starts

[Anshum Gupta]

Sounds good.

Also, I am not a java expert like Uwe, and a few others here so let me know if 
we should leave in the ‘Jigsaw’ part.

David, you added that yesterday and Mike looked at the Lucene release notes and 
let it stay there. So I was wondering if it’s important/reasonable enough to 
highlight in the release notes.

-Anshum



> On Sep 20, 2017, at 8:12 AM, Joel Bernstein  wrote:
> 
> I would also consider changing the order of the list to highlight the most 
> interesting features.
> 
> If I saw this as the top highlight I would think of this is mainly a 
> maintenance release. 
> 
> 
> Indented JSON is now the default response format for all APIs,
>   pass wt=json and/or indent=off to use the previous unindented XML format.
> 
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein  > wrote:
> I just made the edit.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein  > wrote:
> For streaming expressions let's go with:
> 
> Solr 7 Streaming Expressions adds a new statistical programming syntax for
> the statistical analysis of sql queries, random samples, time series and
> graph result sets.
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
> > wrote:
> Cool. How about 7th and 8th bullet points like this. 8th bullet ending in 
> Java 9 future magic still, not that the magic counts but fitting things on 
> roughly a screen full for folks to easily get the gist of the new release is 
> important I think.
> 
> -Christine
> 
> * Solr 7 adds Streaming Expressions, a new statistical programming syntax for
>   the statistical analysis of sql queries, random samples, time series and
>   graph result sets.
> 
> * Solr 7 is tested with and verified to support Java 9
> 
> From: dev@lucene.apache.org  At: 09/20/17 
> 15:54:54
> To:  Christine Poerschke (BLOOMBERG/ LONDON )  
> ,  dev@lucene.apache.org 
> 
> 
> Subject: Re: Release 7.0 process starts
> This looks good, other than the wt=xml correction in #1, as Varun pointed 
> out. Also, I really think we should highlight streaming expressions (Math 
> Engine) even if that means we don’t hit the ‘7 points’ mark :).
> 
> -Anshum
> 
> 
> 
>> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
>> > wrote:
>> 
>> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>> 
>> Below is the revised draft I came up with:
>> 
>> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention 
>> one or _two_ benefits of using the new API especially since we mention that 
>> /solr/ continues to work.)
>> 
>> (Also notice some re-ordering of the bullets starting with the used-by-many 
>> JSON first, then v2 API second, then third collection creation which 
>> mentions faceting and so leads over to the fourth bullet re: facet 
>> refinement. Fifth is the new replica types (that bullet being slightly 
>> longer than the others to explain what the types are about). Sixth is 
>> auto-scaling which mentions future releases (would folks use new replica 
>> types first before moving on to auto-scaling?). Seventh and last then is 
>> Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)
>> 
>> Solr 7.0 Release Highlights:
>> 
>> * Indented JSON is now the default response format for all APIs,
>>   pass wt=json and/or indent=off to use the previous unindented XML format.
>> 
>> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
>>   preferred API, but /solr/ continues to work.
>> 
>> * A new `_default` configset is used if no config is specified at collection
>>   creation. The data-driven functionality of this configset indexes strings 
>> as
>>   analyzed text while at the same time copying to a `*_str` field suitable 
>> for
>>   faceting.
>> 
>> * The JSON Facet API now supports two-phase facet refinement to ensure 
>> accurate
>>   counts and statistics for facet buckets returned in distributed mode.
>> 
>> * Replica Types - Solr 7 supports different replica types, which handle 
>> updates
>>   differently. In addition to pure NRT operation where all replicas build an
>>   index and keep a replication log, you can now also add so called PULL
>>   replicas, achieving the read-speed optimized benefits of a master/slave
>>   setup while at the same time keeping index redundancy.
>> 
>> * Auto-scaling. Solr can now allocate new replicas to nodes using a new auto
>>   scaling policy 

Re: Release 7.0 process starts

[Joel Bernstein]

I would also consider changing the order of the list to highlight the most
interesting features.

If I saw this as the top highlight I would think of this is mainly a
maintenance release.


Indented JSON is now the default response format for all APIs,  pass
wt=json and/or indent=off to use the previous unindented XML format.




Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 11:09 AM, Joel Bernstein  wrote:

> I just made the edit.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein 
> wrote:
>
>> For streaming expressions let's go with:
>>
>> Solr 7 Streaming Expressions adds a new statistical programming syntax for
>> the statistical analysis of sql queries, random samples, time series and
>> graph result sets.
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON)
>>  wrote:
>>
>>> Cool. How about 7th and 8th bullet points like this. 8th bullet ending
>>> in Java 9 future magic still, not that the magic counts but fitting things
>>> on roughly a screen full for folks to easily get the gist of the new
>>> release is important I think.
>>>
>>> -Christine
>>>
>>> * Solr 7 adds Streaming Expressions, a new statistical programming
>>> syntax for
>>> the statistical analysis of sql queries, random samples, time series and
>>> graph result sets.
>>>
>>> * Solr 7 is tested with and verified to support Java 9
>>>
>>> From: dev@lucene.apache.org At: 09/20/17 15:54:54
>>> To: Christine Poerschke (BLOOMBERG/ LONDON ) ,
>>> dev@lucene.apache.org
>>>
>>> Subject: Re: Release 7.0 process starts
>>>
>>> This looks good, other than the wt=xml correction in #1, as Varun
>>> pointed out. Also, I really think we should highlight streaming expressions
>>> (Math Engine) even if that means we don’t hit the ‘7 points’ mark :).
>>>
>>> -Anshum
>>>
>>>
>>>
>>> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
>>> cpoersc...@bloomberg.net> wrote:
>>>
>>> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>>>
>>> Below is the revised draft I came up with:
>>>
>>> (Notice that v2 is the 2nd bullet, though I think it yet needs to
>>> mention one or _two_ benefits of using the new API especially since we
>>> mention that /solr/ continues to work.)
>>>
>>> (Also notice some re-ordering of the bullets starting with the
>>> used-by-many JSON first, then v2 API second, then third collection creation
>>> which mentions faceting and so leads over to the fourth bullet re: facet
>>> refinement. Fifth is the new replica types (that bullet being slightly
>>> longer than the others to explain what the types are about). Sixth is
>>> auto-scaling which mentions future releases (would folks use new replica
>>> types first before moving on to auto-scaling?). Seventh and last then is
>>> Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)
>>>
>>> Solr 7.0 Release Highlights:
>>>
>>> * Indented JSON is now the default response format for all APIs,
>>> pass wt=json and/or indent=off to use the previous unindented XML format.
>>>
>>> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now
>>> the
>>> preferred API, but /solr/ continues to work.
>>>
>>> * A new `_default` configset is used if no config is specified at
>>> collection
>>> creation. The data-driven functionality of this configset indexes
>>> strings as
>>> analyzed text while at the same time copying to a `*_str` field suitable
>>> for
>>> faceting.
>>>
>>> * The JSON Facet API now supports two-phase facet refinement to ensure
>>> accurate
>>> counts and statistics for facet buckets returned in distributed mode.
>>>
>>> * Replica Types - Solr 7 supports different replica types, which handle
>>> updates
>>> differently. In addition to pure NRT operation where all replicas build
>>> an
>>> index and keep a replication log, you can now also add so called PULL
>>> replicas, achieving the read-speed optimized benefits of a master/slave
>>> setup while at the same time keeping index redundancy.
>>>
>>> * Auto-scaling. Solr can now allocate new replicas to nodes using a new
>>> auto
>>> scaling policy framework. This framework will in future releases enable
>>> Solr
>>> to move shards around based on load, disk etc.
>>>
>>> * Solr 7 is tested with and verified to support Java 9.
>>>
>>> From: dev@lucene.apache.org At: 09/20/17 15:02:38
>>> To: dev@lucene.apache.org
>>> Subject: Re: Release 7.0 process starts
>>>
>>>
>>>
>>> On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl 
>>> wrote:
>>>
 And please, I was serious about choosing 7 major features and not
 adding random single improvements. The list has already creeped from 7 to 9
 bullets. If you want to add something, then ask youself which of the other
 bullets that are less important to 

Re: Release 7.0 process starts

[Joel Bernstein]

I just made the edit.

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 11:06 AM, Joel Bernstein  wrote:

> For streaming expressions let's go with:
>
> Solr 7 Streaming Expressions adds a new statistical programming syntax for
> the statistical analysis of sql queries, random samples, time series and
> graph result sets.
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON)
>  wrote:
>
>> Cool. How about 7th and 8th bullet points like this. 8th bullet ending
>> in Java 9 future magic still, not that the magic counts but fitting things
>> on roughly a screen full for folks to easily get the gist of the new
>> release is important I think.
>>
>> -Christine
>>
>> * Solr 7 adds Streaming Expressions, a new statistical programming syntax
>> for
>> the statistical analysis of sql queries, random samples, time series and
>> graph result sets.
>>
>> * Solr 7 is tested with and verified to support Java 9
>>
>> From: dev@lucene.apache.org At: 09/20/17 15:54:54
>> To: Christine Poerschke (BLOOMBERG/ LONDON ) ,
>> dev@lucene.apache.org
>>
>> Subject: Re: Release 7.0 process starts
>>
>> This looks good, other than the wt=xml correction in #1, as Varun pointed
>> out. Also, I really think we should highlight streaming expressions (Math
>> Engine) even if that means we don’t hit the ‘7 points’ mark :).
>>
>> -Anshum
>>
>>
>>
>> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
>> cpoersc...@bloomberg.net> wrote:
>>
>> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>>
>> Below is the revised draft I came up with:
>>
>> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention
>> one or _two_ benefits of using the new API especially since we mention that
>> /solr/ continues to work.)
>>
>> (Also notice some re-ordering of the bullets starting with the
>> used-by-many JSON first, then v2 API second, then third collection creation
>> which mentions faceting and so leads over to the fourth bullet re: facet
>> refinement. Fifth is the new replica types (that bullet being slightly
>> longer than the others to explain what the types are about). Sixth is
>> auto-scaling which mentions future releases (would folks use new replica
>> types first before moving on to auto-scaling?). Seventh and last then is
>> Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)
>>
>> Solr 7.0 Release Highlights:
>>
>> * Indented JSON is now the default response format for all APIs,
>> pass wt=json and/or indent=off to use the previous unindented XML format.
>>
>> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now
>> the
>> preferred API, but /solr/ continues to work.
>>
>> * A new `_default` configset is used if no config is specified at
>> collection
>> creation. The data-driven functionality of this configset indexes strings
>> as
>> analyzed text while at the same time copying to a `*_str` field suitable
>> for
>> faceting.
>>
>> * The JSON Facet API now supports two-phase facet refinement to ensure
>> accurate
>> counts and statistics for facet buckets returned in distributed mode.
>>
>> * Replica Types - Solr 7 supports different replica types, which handle
>> updates
>> differently. In addition to pure NRT operation where all replicas build an
>> index and keep a replication log, you can now also add so called PULL
>> replicas, achieving the read-speed optimized benefits of a master/slave
>> setup while at the same time keeping index redundancy.
>>
>> * Auto-scaling. Solr can now allocate new replicas to nodes using a new
>> auto
>> scaling policy framework. This framework will in future releases enable
>> Solr
>> to move shards around based on load, disk etc.
>>
>> * Solr 7 is tested with and verified to support Java 9.
>>
>> From: dev@lucene.apache.org At: 09/20/17 15:02:38
>> To: dev@lucene.apache.org
>> Subject: Re: Release 7.0 process starts
>>
>>
>>
>> On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl 
>> wrote:
>>
>>> And please, I was serious about choosing 7 major features and not adding
>>> random single improvements. The list has already creeped from 7 to 9
>>> bullets. If you want to add something, then ask youself which of the other
>>> bullets that are less important to MOST USERS and then replace that bullet
>>> instead of adding more. Agree?
>>>
>>
>> I agree with that very much!  *Each bullet added de-values the list as a
>> whole.  *IMO the Java 9 bullet can be removed (too few are even using it
>> yet) and we get to 8 bullets; and those 8 are pretty good.
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>>
>>
>

Re: Release 7.0 process starts

[Christine Poerschke (BLOOMBERG/ LONDON)]

Sure.

Joel, could you edit directly in the WIKI? (I'm about to go into a meeting.)

Thanks!

Christine

From: dev@lucene.apache.org At: 09/20/17 16:07:11To:  Christine Poerschke 
(BLOOMBERG/ LONDON ) ,  dev@lucene.apache.org
Subject: Re: Release 7.0 process starts

For streaming expressions let's go with:

Solr 7 Streaming Expressions adds a new statistical programming syntax for
the statistical analysis of sql queries, random samples, time series and
graph result sets.


Joel Bernstein
http://joelsolr.blogspot.com/
 
On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
 wrote:

Cool. How about 7th and 8th bullet points like this. 8th bullet ending in Java 
9 future magic still, not that the magic counts but fitting things on roughly a 
screen full for folks to easily get the gist of the new release is important I 
think.

-Christine

* Solr 7 adds Streaming Expressions, a new statistical programming syntax for
  the statistical analysis of sql queries, random samples, time series and
  graph result sets.

* Solr 7 is tested with and verified to support Java 9

From: dev@lucene.apache.org At: 09/20/17 15:54:54To:  Christine Poerschke 
(BLOOMBERG/ LONDON ) ,  dev@lucene.apache.org

Subject: Re: Release 7.0 process starts

This looks good, other than the wt=xml correction in #1, as Varun pointed out. 
Also, I really think we should highlight streaming expressions (Math Engine) 
even if that means we don’t hit the ‘7 points’ mark :).

-Anshum


 

On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
 wrote:
Totally agree with choosing _7_ highlights for the Solr _7_ release!

Below is the revised draft I came up with:

(Notice that v2 is the 2nd bullet, though I think it yet needs to mention one 
or _two_ benefits of using the new API especially since we mention that /solr/ 
continues to work.)

(Also notice some re-ordering of the bullets starting with the used-by-many 
JSON first, then v2 API second, then third collection creation which mentions 
faceting and so leads over to the fourth bullet re: facet refinement. Fifth is 
the new replica types (that bullet being slightly longer than the others to 
explain what the types are about). Sixth is auto-scaling which mentions future 
releases (would folks use new replica types first before moving on to 
auto-scaling?). Seventh and last then is Solr _7_ mention with Java _9_ i.e. 
the just-arrived future again there.)

Solr 7.0 Release Highlights:

* Indented JSON is now the default response format for all APIs,
  pass wt=json and/or indent=off to use the previous unindented XML format.

* The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
  preferred API, but /solr/ continues to work.

* A new `_default` configset is used if no config is specified at collection
  creation. The data-driven functionality of this configset indexes strings as
  analyzed text while at the same time copying to a `*_str` field suitable for
  faceting.

* The JSON Facet API now supports two-phase facet refinement to ensure accurate
  counts and statistics for facet buckets returned in distributed mode.

* Replica Types - Solr 7 supports different replica types, which handle updates
  differently. In addition to pure NRT operation where all replicas build an
  index and keep a replication log, you can now also add so called PULL
  replicas, achieving the read-speed optimized benefits of a master/slave
  setup while at the same time keeping index redundancy.

* Auto-scaling. Solr can now allocate new replicas to nodes using a new auto
  scaling policy framework. This framework will in future releases enable Solr
  to move shards around based on load, disk etc.

* Solr 7 is tested with and verified to support Java 9.

From: dev@lucene.apache.org At: 09/20/17 15:02:38To:  dev@lucene.apache.org
Subject: Re: Release 7.0 process starts


On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl  wrote:
And please, I was serious about choosing 7 major features and not adding random 
single improvements. The list has already creeped from 7 to 9 bullets. If you 
want to add something, then ask youself which of the other bullets that are 
less important to MOST USERS and then replace that bullet instead of adding 
more. Agree?

I agree with that very much!  Each bullet added de-values the list as a whole.  
IMO the Java 9 bullet can be removed (too few are even using it yet) and we get 
to 8 bullets; and those 8 are pretty good. 
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Re: Release 7.0 process starts

[Joel Bernstein]

For streaming expressions let's go with:

Solr 7 Streaming Expressions adds a new statistical programming syntax for
the statistical analysis of sql queries, random samples, time series and
graph result sets.


Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 11:01 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> Cool. How about 7th and 8th bullet points like this. 8th bullet ending in
> Java 9 future magic still, not that the magic counts but fitting things on
> roughly a screen full for folks to easily get the gist of the new release
> is important I think.
>
> -Christine
>
> * Solr 7 adds Streaming Expressions, a new statistical programming syntax
> for
> the statistical analysis of sql queries, random samples, time series and
> graph result sets.
>
> * Solr 7 is tested with and verified to support Java 9
>
> From: dev@lucene.apache.org At: 09/20/17 15:54:54
> To: Christine Poerschke (BLOOMBERG/ LONDON ) ,
> dev@lucene.apache.org
>
> Subject: Re: Release 7.0 process starts
>
> This looks good, other than the wt=xml correction in #1, as Varun pointed
> out. Also, I really think we should highlight streaming expressions (Math
> Engine) even if that means we don’t hit the ‘7 points’ mark :).
>
> -Anshum
>
>
>
> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>
> Below is the revised draft I came up with:
>
> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention
> one or _two_ benefits of using the new API especially since we mention that
> /solr/ continues to work.)
>
> (Also notice some re-ordering of the bullets starting with the
> used-by-many JSON first, then v2 API second, then third collection creation
> which mentions faceting and so leads over to the fourth bullet re: facet
> refinement. Fifth is the new replica types (that bullet being slightly
> longer than the others to explain what the types are about). Sixth is
> auto-scaling which mentions future releases (would folks use new replica
> types first before moving on to auto-scaling?). Seventh and last then is
> Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)
>
> Solr 7.0 Release Highlights:
>
> * Indented JSON is now the default response format for all APIs,
> pass wt=json and/or indent=off to use the previous unindented XML format.
>
> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
> preferred API, but /solr/ continues to work.
>
> * A new `_default` configset is used if no config is specified at
> collection
> creation. The data-driven functionality of this configset indexes strings
> as
> analyzed text while at the same time copying to a `*_str` field suitable
> for
> faceting.
>
> * The JSON Facet API now supports two-phase facet refinement to ensure
> accurate
> counts and statistics for facet buckets returned in distributed mode.
>
> * Replica Types - Solr 7 supports different replica types, which handle
> updates
> differently. In addition to pure NRT operation where all replicas build an
> index and keep a replication log, you can now also add so called PULL
> replicas, achieving the read-speed optimized benefits of a master/slave
> setup while at the same time keeping index redundancy.
>
> * Auto-scaling. Solr can now allocate new replicas to nodes using a new
> auto
> scaling policy framework. This framework will in future releases enable
> Solr
> to move shards around based on load, disk etc.
>
> * Solr 7 is tested with and verified to support Java 9.
>
> From: dev@lucene.apache.org At: 09/20/17 15:02:38
> To: dev@lucene.apache.org
> Subject: Re: Release 7.0 process starts
>
>
>
> On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl  wrote:
>
>> And please, I was serious about choosing 7 major features and not adding
>> random single improvements. The list has already creeped from 7 to 9
>> bullets. If you want to add something, then ask youself which of the other
>> bullets that are less important to MOST USERS and then replace that bullet
>> instead of adding more. Agree?
>>
>
> I agree with that very much!  *Each bullet added de-values the list as a
> whole.  *IMO the Java 9 bullet can be removed (too few are even using it
> yet) and we get to 8 bullets; and those 8 are pretty good.
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>
>
>

[jira] [Updated] (LUCENE-7973) Update dictionary version for Ukrainian analyzer

[Mike Drob (JIRA)]

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

Mike Drob updated LUCENE-7973:
--
Summary: Update dictionary version for Ukrainian analyzer  (was: Update 
dictionary version for Urainian analyzer)

> Update dictionary version for Ukrainian analyzer
> 
>
> Key: LUCENE-7973
> URL: https://issues.apache.org/jira/browse/LUCENE-7973
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>
> Update morfologik dictionary version to 3.9.0 for Ukrainian analyzer.
> There's 60K of new lemmas there along with some other improvements and fixes, 
> particularly Ukrainian town names have been synchronized with official 
> standard.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release 7.0 process starts

[Christine Poerschke (BLOOMBERG/ LONDON)]

Cool. How about 7th and 8th bullet points like this. 8th bullet ending in Java 
9 future magic still, not that the magic counts but fitting things on roughly a 
screen full for folks to easily get the gist of the new release is important I 
think.

-Christine

* Solr 7 adds Streaming Expressions, a new statistical programming syntax for
  the statistical analysis of sql queries, random samples, time series and
  graph result sets.

* Solr 7 is tested with and verified to support Java 9

From: dev@lucene.apache.org At: 09/20/17 15:54:54To:  Christine Poerschke 
(BLOOMBERG/ LONDON ) ,  dev@lucene.apache.org
Subject: Re: Release 7.0 process starts

This looks good, other than the wt=xml correction in #1, as Varun pointed out. 
Also, I really think we should highlight streaming expressions (Math Engine) 
even if that means we don’t hit the ‘7 points’ mark :).

-Anshum


 

On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
 wrote:
Totally agree with choosing _7_ highlights for the Solr _7_ release!

Below is the revised draft I came up with:

(Notice that v2 is the 2nd bullet, though I think it yet needs to mention one 
or _two_ benefits of using the new API especially since we mention that /solr/ 
continues to work.)

(Also notice some re-ordering of the bullets starting with the used-by-many 
JSON first, then v2 API second, then third collection creation which mentions 
faceting and so leads over to the fourth bullet re: facet refinement. Fifth is 
the new replica types (that bullet being slightly longer than the others to 
explain what the types are about). Sixth is auto-scaling which mentions future 
releases (would folks use new replica types first before moving on to 
auto-scaling?). Seventh and last then is Solr _7_ mention with Java _9_ i.e. 
the just-arrived future again there.)

Solr 7.0 Release Highlights:

* Indented JSON is now the default response format for all APIs,
  pass wt=json and/or indent=off to use the previous unindented XML format.

* The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
  preferred API, but /solr/ continues to work.

* A new `_default` configset is used if no config is specified at collection
  creation. The data-driven functionality of this configset indexes strings as
  analyzed text while at the same time copying to a `*_str` field suitable for
  faceting.

* The JSON Facet API now supports two-phase facet refinement to ensure accurate
  counts and statistics for facet buckets returned in distributed mode.

* Replica Types - Solr 7 supports different replica types, which handle updates
  differently. In addition to pure NRT operation where all replicas build an
  index and keep a replication log, you can now also add so called PULL
  replicas, achieving the read-speed optimized benefits of a master/slave
  setup while at the same time keeping index redundancy.

* Auto-scaling. Solr can now allocate new replicas to nodes using a new auto
  scaling policy framework. This framework will in future releases enable Solr
  to move shards around based on load, disk etc.

* Solr 7 is tested with and verified to support Java 9.

From: dev@lucene.apache.org At: 09/20/17 15:02:38To:  dev@lucene.apache.org
Subject: Re: Release 7.0 process starts


On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl  wrote:
And please, I was serious about choosing 7 major features and not adding random 
single improvements. The list has already creeped from 7 to 9 bullets. If you 
want to add something, then ask youself which of the other bullets that are 
less important to MOST USERS and then replace that bullet instead of adding 
more. Agree?

I agree with that very much!  Each bullet added de-values the list as a whole.  
IMO the Java 9 bullet can be removed (too few are even using it yet) and we get 
to 8 bullets; and those 8 are pretty good. 
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Re: Release 7.0 process starts

[Anshum Gupta]

Christine, can you update the draft with the changes ?

-Anshum



> On Sep 20, 2017, at 7:54 AM, Anshum Gupta  wrote:
> 
> This looks good, other than the wt=xml correction in #1, as Varun pointed 
> out. Also, I really think we should highlight streaming expressions (Math 
> Engine) even if that means we don’t hit the ‘7 points’ mark :).
> 
> -Anshum
> 
> 
> 
>> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
>> > wrote:
>> 
>> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>> 
>> Below is the revised draft I came up with:
>> 
>> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention 
>> one or _two_ benefits of using the new API especially since we mention that 
>> /solr/ continues to work.)
>> 
>> (Also notice some re-ordering of the bullets starting with the used-by-many 
>> JSON first, then v2 API second, then third collection creation which 
>> mentions faceting and so leads over to the fourth bullet re: facet 
>> refinement. Fifth is the new replica types (that bullet being slightly 
>> longer than the others to explain what the types are about). Sixth is 
>> auto-scaling which mentions future releases (would folks use new replica 
>> types first before moving on to auto-scaling?). Seventh and last then is 
>> Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)
>> 
>> Solr 7.0 Release Highlights:
>> 
>> * Indented JSON is now the default response format for all APIs,
>>   pass wt=json and/or indent=off to use the previous unindented XML format.
>> 
>> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
>>   preferred API, but /solr/ continues to work.
>> 
>> * A new `_default` configset is used if no config is specified at collection
>>   creation. The data-driven functionality of this configset indexes strings 
>> as
>>   analyzed text while at the same time copying to a `*_str` field suitable 
>> for
>>   faceting.
>> 
>> * The JSON Facet API now supports two-phase facet refinement to ensure 
>> accurate
>>   counts and statistics for facet buckets returned in distributed mode.
>> 
>> * Replica Types - Solr 7 supports different replica types, which handle 
>> updates
>>   differently. In addition to pure NRT operation where all replicas build an
>>   index and keep a replication log, you can now also add so called PULL
>>   replicas, achieving the read-speed optimized benefits of a master/slave
>>   setup while at the same time keeping index redundancy.
>> 
>> * Auto-scaling. Solr can now allocate new replicas to nodes using a new auto
>>   scaling policy framework. This framework will in future releases enable 
>> Solr
>>   to move shards around based on load, disk etc.
>> 
>> * Solr 7 is tested with and verified to support Java 9.
>> 
>> From: dev@lucene.apache.org  At: 09/20/17 
>> 15:02:38
>> To:  dev@lucene.apache.org 
>> Subject: Re: Release 7.0 process starts
>> 
>> 
>> On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl > > wrote:
>> And please, I was serious about choosing 7 major features and not adding 
>> random single improvements. The list has already creeped from 7 to 9 
>> bullets. If you want to add something, then ask youself which of the other 
>> bullets that are less important to MOST USERS and then replace that bullet 
>> instead of adding more. Agree?
>> 
>> I agree with that very much!  Each bullet added de-values the list as a 
>> whole.  IMO the Java 9 bullet can be removed (too few are even using it yet) 
>> and we get to 8 bullets; and those 8 are pretty good. 
>> -- 
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley 
>>  | Book: 
>> http://www.solrenterprisesearchserver.com 
>> 

[jira] [Closed] (SOLR-7407) Enable JSON API for any path

[Noble Paul (JIRA)]

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

Noble Paul closed SOLR-7407.

Resolution: Won't Fix

V2 API takes care of most of this

> Enable JSON API for any path 
> -
>
> Key: SOLR-7407
> URL: https://issues.apache.org/jira/browse/SOLR-7407
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-7407.patch
>
>
> It should be possible to make the JSON API support enabled for any 
> RequestHandler. This would mean annotating the RequestHandler with 
> appropriate interfaces and metadata 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release 7.0 process starts

[Anshum Gupta]

This looks good, other than the wt=xml correction in #1, as Varun pointed out. 
Also, I really think we should highlight streaming expressions (Math Engine) 
even if that means we don’t hit the ‘7 points’ mark :).

-Anshum



> On Sep 20, 2017, at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
>  wrote:
> 
> Totally agree with choosing _7_ highlights for the Solr _7_ release!
> 
> Below is the revised draft I came up with:
> 
> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention one 
> or _two_ benefits of using the new API especially since we mention that 
> /solr/ continues to work.)
> 
> (Also notice some re-ordering of the bullets starting with the used-by-many 
> JSON first, then v2 API second, then third collection creation which mentions 
> faceting and so leads over to the fourth bullet re: facet refinement. Fifth 
> is the new replica types (that bullet being slightly longer than the others 
> to explain what the types are about). Sixth is auto-scaling which mentions 
> future releases (would folks use new replica types first before moving on to 
> auto-scaling?). Seventh and last then is Solr _7_ mention with Java _9_ i.e. 
> the just-arrived future again there.)
> 
> Solr 7.0 Release Highlights:
> 
> * Indented JSON is now the default response format for all APIs,
>   pass wt=json and/or indent=off to use the previous unindented XML format.
> 
> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
>   preferred API, but /solr/ continues to work.
> 
> * A new `_default` configset is used if no config is specified at collection
>   creation. The data-driven functionality of this configset indexes strings as
>   analyzed text while at the same time copying to a `*_str` field suitable for
>   faceting.
> 
> * The JSON Facet API now supports two-phase facet refinement to ensure 
> accurate
>   counts and statistics for facet buckets returned in distributed mode.
> 
> * Replica Types - Solr 7 supports different replica types, which handle 
> updates
>   differently. In addition to pure NRT operation where all replicas build an
>   index and keep a replication log, you can now also add so called PULL
>   replicas, achieving the read-speed optimized benefits of a master/slave
>   setup while at the same time keeping index redundancy.
> 
> * Auto-scaling. Solr can now allocate new replicas to nodes using a new auto
>   scaling policy framework. This framework will in future releases enable Solr
>   to move shards around based on load, disk etc.
> 
> * Solr 7 is tested with and verified to support Java 9.
> 
> From: dev@lucene.apache.org At: 09/20/17 15:02:38
> To:  dev@lucene.apache.org 
> Subject: Re: Release 7.0 process starts
> 
> 
> On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl  > wrote:
> And please, I was serious about choosing 7 major features and not adding 
> random single improvements. The list has already creeped from 7 to 9 bullets. 
> If you want to add something, then ask youself which of the other bullets 
> that are less important to MOST USERS and then replace that bullet instead of 
> adding more. Agree?
> 
> I agree with that very much!  Each bullet added de-values the list as a 
> whole.  IMO the Java 9 bullet can be removed (too few are even using it yet) 
> and we get to 8 bullets; and those 8 are pretty good. 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
> 

Re: Release 7.0 process starts

[Walter Underwood]

I’m fine with more than seven bullet points. In fact, when I see a list of 8 or 
9 things, I know it is a real list, and not someone just trying to get to the 
magic 7 or 10.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Sep 20, 2017, at 7:39 AM, Joel Bernstein  wrote:
> 
> I think Solr 7 is a truly exciting release stacked with interesting new 
> features. So let's not drop off anything really interesting just to keep it 
> to 7 bullet points. But we should prune the list to include the high impact 
> features. 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 10:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
> > wrote:
> Totally agree with choosing _7_ highlights for the Solr _7_ release!
> 
> Below is the revised draft I came up with:
> 
> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention one 
> or _two_ benefits of using the new API especially since we mention that 
> /solr/ continues to work.)
> 
> (Also notice some re-ordering of the bullets starting with the used-by-many 
> JSON first, then v2 API second, then third collection creation which mentions 
> faceting and so leads over to the fourth bullet re: facet refinement. Fifth 
> is the new replica types (that bullet being slightly longer than the others 
> to explain what the types are about). Sixth is auto-scaling which mentions 
> future releases (would folks use new replica types first before moving on to 
> auto-scaling?). Seventh and last then is Solr _7_ mention with Java _9_ i.e. 
> the just-arrived future again there.)
> 
> Solr 7.0 Release Highlights:
> 
> * Indented JSON is now the default response format for all APIs,
>   pass wt=json and/or indent=off to use the previous unindented XML format.
> 
> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
>   preferred API, but /solr/ continues to work.
> 
> * A new `_default` configset is used if no config is specified at collection
>   creation. The data-driven functionality of this configset indexes strings as
>   analyzed text while at the same time copying to a `*_str` field suitable for
>   faceting.
> 
> * The JSON Facet API now supports two-phase facet refinement to ensure 
> accurate
>   counts and statistics for facet buckets returned in distributed mode.
> 
> * Replica Types - Solr 7 supports different replica types, which handle 
> updates
>   differently. In addition to pure NRT operation where all replicas build an
>   index and keep a replication log, you can now also add so called PULL
>   replicas, achieving the read-speed optimized benefits of a master/slave
>   setup while at the same time keeping index redundancy.
> 
> * Auto-scaling. Solr can now allocate new replicas to nodes using a new auto
>   scaling policy framework. This framework will in future releases enable Solr
>   to move shards around based on load, disk etc.
> 
> * Solr 7 is tested with and verified to support Java 9.
> 
> From: dev@lucene.apache.org  At: 09/20/17 
> 15:02:38
> To:  dev@lucene.apache.org 
> Subject: Re: Release 7.0 process starts
> 
> 
> On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl  > wrote:
> And please, I was serious about choosing 7 major features and not adding 
> random single improvements. The list has already creeped from 7 to 9 bullets. 
> If you want to add something, then ask youself which of the other bullets 
> that are less important to MOST USERS and then replace that bullet instead of 
> adding more. Agree?
> 
> I agree with that very much!  Each bullet added de-values the list as a 
> whole.  IMO the Java 9 bullet can be removed (too few are even using it yet) 
> and we get to 8 bullets; and those 8 are pretty good. 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
> 

[jira] [Updated] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-8389:

Fix Version/s: (was: 6.0)

> Convert CDCR peer cluster and other configurations into collection properties 
> modifiable via APIs
> -
>
> Key: SOLR-8389
> URL: https://issues.apache.org/jira/browse/SOLR-8389
> Project: Solr
>  Issue Type: Improvement
>  Components: CDCR, SolrCloud
>Reporter: Shalin Shekhar Mangar
>
> CDCR configuration is kept inside solrconfig.xml which makes it difficult to 
> add or change peer cluster configuration.
> I propose to move all CDCR config to collection level properties in cluster 
> state so that they can be modified using the existing modify collection API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release 7.0 process starts

[Varun Thacker]

"pass wt=json and/or indent=off to use the previous unindented XML format"
: Should it be pass wt=xml or am I misunderstanding this statement ?

Additionally should we add a bullet regarding point fields ?

* Numeric and date data use point field types by default. All trie fields
types have been deprecated

On Wed, Sep 20, 2017 at 7:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>
> Below is the revised draft I came up with:
>
> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention
> one or _two_ benefits of using the new API especially since we mention that
> /solr/ continues to work.)
>
> (Also notice some re-ordering of the bullets starting with the
> used-by-many JSON first, then v2 API second, then third collection creation
> which mentions faceting and so leads over to the fourth bullet re: facet
> refinement. Fifth is the new replica types (that bullet being slightly
> longer than the others to explain what the types are about). Sixth is
> auto-scaling which mentions future releases (would folks use new replica
> types first before moving on to auto-scaling?). Seventh and last then is
> Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)
>
> Solr 7.0 Release Highlights:
>
> * Indented JSON is now the default response format for all APIs,
> pass wt=json and/or indent=off to use the previous unindented XML format.
>
> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
> preferred API, but /solr/ continues to work.
>
> * A new `_default` configset is used if no config is specified at
> collection
> creation. The data-driven functionality of this configset indexes strings
> as
> analyzed text while at the same time copying to a `*_str` field suitable
> for
> faceting.
>
> * The JSON Facet API now supports two-phase facet refinement to ensure
> accurate
> counts and statistics for facet buckets returned in distributed mode.
>
> * Replica Types - Solr 7 supports different replica types, which handle
> updates
> differently. In addition to pure NRT operation where all replicas build an
> index and keep a replication log, you can now also add so called PULL
> replicas, achieving the read-speed optimized benefits of a master/slave
> setup while at the same time keeping index redundancy.
>
> * Auto-scaling. Solr can now allocate new replicas to nodes using a new
> auto
> scaling policy framework. This framework will in future releases enable
> Solr
> to move shards around based on load, disk etc.
>
> * Solr 7 is tested with and verified to support Java 9.
>
> From: dev@lucene.apache.org At: 09/20/17 15:02:38
> To: dev@lucene.apache.org
> Subject: Re: Release 7.0 process starts
>
>
>
> On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl  wrote:
>
>> And please, I was serious about choosing 7 major features and not adding
>> random single improvements. The list has already creeped from 7 to 9
>> bullets. If you want to add something, then ask youself which of the other
>> bullets that are less important to MOST USERS and then replace that bullet
>> instead of adding more. Agree?
>>
>
> I agree with that very much!  *Each bullet added de-values the list as a
> whole.  *IMO the Java 9 bullet can be removed (too few are even using it
> yet) and we get to 8 bullets; and those 8 are pretty good.
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>
>

Re: Release 7.0 process starts

[Joel Bernstein]

I think Solr 7 is a truly exciting release stacked with interesting new
features. So let's not drop off anything really interesting just to keep it
to 7 bullet points. But we should prune the list to include the high impact
features.

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Sep 20, 2017 at 10:21 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> Totally agree with choosing _7_ highlights for the Solr _7_ release!
>
> Below is the revised draft I came up with:
>
> (Notice that v2 is the 2nd bullet, though I think it yet needs to mention
> one or _two_ benefits of using the new API especially since we mention that
> /solr/ continues to work.)
>
> (Also notice some re-ordering of the bullets starting with the
> used-by-many JSON first, then v2 API second, then third collection creation
> which mentions faceting and so leads over to the fourth bullet re: facet
> refinement. Fifth is the new replica types (that bullet being slightly
> longer than the others to explain what the types are about). Sixth is
> auto-scaling which mentions future releases (would folks use new replica
> types first before moving on to auto-scaling?). Seventh and last then is
> Solr _7_ mention with Java _9_ i.e. the just-arrived future again there.)
>
> Solr 7.0 Release Highlights:
>
> * Indented JSON is now the default response format for all APIs,
> pass wt=json and/or indent=off to use the previous unindented XML format.
>
> * The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
> preferred API, but /solr/ continues to work.
>
> * A new `_default` configset is used if no config is specified at
> collection
> creation. The data-driven functionality of this configset indexes strings
> as
> analyzed text while at the same time copying to a `*_str` field suitable
> for
> faceting.
>
> * The JSON Facet API now supports two-phase facet refinement to ensure
> accurate
> counts and statistics for facet buckets returned in distributed mode.
>
> * Replica Types - Solr 7 supports different replica types, which handle
> updates
> differently. In addition to pure NRT operation where all replicas build an
> index and keep a replication log, you can now also add so called PULL
> replicas, achieving the read-speed optimized benefits of a master/slave
> setup while at the same time keeping index redundancy.
>
> * Auto-scaling. Solr can now allocate new replicas to nodes using a new
> auto
> scaling policy framework. This framework will in future releases enable
> Solr
> to move shards around based on load, disk etc.
>
> * Solr 7 is tested with and verified to support Java 9.
>
> From: dev@lucene.apache.org At: 09/20/17 15:02:38
> To: dev@lucene.apache.org
> Subject: Re: Release 7.0 process starts
>
>
>
> On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl  wrote:
>
>> And please, I was serious about choosing 7 major features and not adding
>> random single improvements. The list has already creeped from 7 to 9
>> bullets. If you want to add something, then ask youself which of the other
>> bullets that are less important to MOST USERS and then replace that bullet
>> instead of adding more. Agree?
>>
>
> I agree with that very much!  *Each bullet added de-values the list as a
> whole.  *IMO the Java 9 bullet can be removed (too few are even using it
> yet) and we get to 8 bullets; and those 8 are pretty good.
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>
>

Re: Release 7.0 process starts

[Christine Poerschke (BLOOMBERG/ LONDON)]

Totally agree with choosing _7_ highlights for the Solr _7_ release!

Below is the revised draft I came up with:

(Notice that v2 is the 2nd bullet, though I think it yet needs to mention one 
or _two_ benefits of using the new API especially since we mention that /solr/ 
continues to work.)

(Also notice some re-ordering of the bullets starting with the used-by-many 
JSON first, then v2 API second, then third collection creation which mentions 
faceting and so leads over to the fourth bullet re: facet refinement. Fifth is 
the new replica types (that bullet being slightly longer than the others to 
explain what the types are about). Sixth is auto-scaling which mentions future 
releases (would folks use new replica types first before moving on to 
auto-scaling?). Seventh and last then is Solr _7_ mention with Java _9_ i.e. 
the just-arrived future again there.)

Solr 7.0 Release Highlights:

* Indented JSON is now the default response format for all APIs,
  pass wt=json and/or indent=off to use the previous unindented XML format.

* The new v2 API, exposed at /api/ and also supported via SolrJ, is now the
  preferred API, but /solr/ continues to work.

* A new `_default` configset is used if no config is specified at collection
  creation. The data-driven functionality of this configset indexes strings as
  analyzed text while at the same time copying to a `*_str` field suitable for
  faceting.

* The JSON Facet API now supports two-phase facet refinement to ensure accurate
  counts and statistics for facet buckets returned in distributed mode.

* Replica Types - Solr 7 supports different replica types, which handle updates
  differently. In addition to pure NRT operation where all replicas build an
  index and keep a replication log, you can now also add so called PULL
  replicas, achieving the read-speed optimized benefits of a master/slave
  setup while at the same time keeping index redundancy.

* Auto-scaling. Solr can now allocate new replicas to nodes using a new auto
  scaling policy framework. This framework will in future releases enable Solr
  to move shards around based on load, disk etc.

* Solr 7 is tested with and verified to support Java 9.

From: dev@lucene.apache.org At: 09/20/17 15:02:38To:  dev@lucene.apache.org
Subject: Re: Release 7.0 process starts


On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl  wrote:
And please, I was serious about choosing 7 major features and not adding random 
single improvements. The list has already creeped from 7 to 9 bullets. If you 
want to add something, then ask youself which of the other bullets that are 
less important to MOST USERS and then replace that bullet instead of adding 
more. Agree?

I agree with that very much!  Each bullet added de-values the list as a whole.  
IMO the Java 9 bullet can be removed (too few are even using it yet) and we get 
to 8 bullets; and those 8 are pretty good. 
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Re: Release 7.0 process starts

[David Smiley]

On Wed, Sep 20, 2017 at 9:16 AM Jan Høydahl  wrote:

> And please, I was serious about choosing 7 major features and not adding
> random single improvements. The list has already creeped from 7 to 9
> bullets. If you want to add something, then ask youself which of the other
> bullets that are less important to MOST USERS and then replace that bullet
> instead of adding more. Agree?
>

I agree with that very much!  *Each bullet added de-values the list as a
whole.  *IMO the Java 9 bullet can be removed (too few are even using it
yet) and we get to 8 bullets; and those 8 are pretty good.
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Release 7.0 process starts

[Anshum Gupta]

Thanks Jan, Mike, and everyone else. This reads so much better, and I agree 
that this should be the standard structure.

I’m just updating the website right now. Once done, I plan to send out the 
notification. In case someone still wants to add/edit the notes, “now" is the 
time.

-Anshum



> On Sep 20, 2017, at 6:16 AM, Jan Høydahl  wrote:
> 
> Ok, so I took the liberty of updating 
> https://wiki.apache.org/solr/ReleaseNote70 
>  with my changes
> Note that the previous version of the release notes can still be found at 
> https://wiki.apache.org/solr/ReleaseNote70?action=info 
>  for reference
> 
> Joel, look at the bullet I re-added about Math expressions, feel free to jump 
> in and modify now that it is in the Wiki.
> 
> Cassandra, I totally agree about ref guide syncing and communicating one 
> message.
> Also the practice of listing some of the major features introduced in 6.x is 
> a good thing.
> If you have wording improvements to my summaries, please chime in, I’m not a 
> technical writer :)
> 
> And please, I was serious about choosing 7 major features and not adding 
> random single improvements. The list has already creeped from 7 to 9 bullets. 
> If you want to add something, then ask youself which of the other bullets 
> that are less important to MOST USERS and then replace that bullet instead of 
> adding more. Agree?
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 20. sep. 2017 kl. 14.34 skrev Joel Bernstein > >:
>> 
>> Hi Jan,
>> 
>> I added a note for Streaming Expressions in the comments. Could you add that 
>> to the release notes?
>> 
>> 
>> 
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ 
>> 
>> On Wed, Sep 20, 2017 at 8:17 AM, David Smiley > > wrote:
>> Excellent Jan!  Editorial summaries should be the standard our users expect.
>> 
>> 
>> On Wed, Sep 20, 2017 at 7:51 AM Jan Høydahl > > wrote:
>> I think the (Solr) release notes feels more like a dump of JIRA descriptions 
>> than an editorial summary of main highlights.
>> People who want to dive deep can read CHANGES, let’s choose top-7 largest 
>> changes, describe them editorially and refer to CHANGES for the rest 
>> including upgrade notes?
>> 
>> I made a total re-write here 
>> https://gist.github.com/3afd5095834ee9e5d60b2eb304c21bec 
>>  including a 
>> general warning at the end that this is a major release that removes 
>> deprecated stuff and that you should read the upgrade notes.
>> Anshum, feel free to disagree and discard or use at will!
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 
>> 
>>> 19. sep. 2017 kl. 22.44 skrev Anshum Gupta >> >:
>>> 
>>> Please find the release notes here:
>>> 
>>> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote70 
>>> 
>>> 
>>> Solr: https://wiki.apache.org/solr/ReleaseNote70 
>>>  
>>> 
>>> I am cleaning up the ‘upgrading from 6x’ section to make it shorter but 
>>> feel free to either fix/add things to this. I pushed the artifacts last 
>>> night so there are still about 8 hours to the 24 hours period. 
>>> 
>>> I’ll use the 8 hours to fix the website etc. and announce once all of this 
>>> is wrapped up!
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
 On Aug 28, 2017, at 10:46 PM, Varun Thacker > wrote:
 
 I don't think holding up the release process infinitely till we stabilize 
 all the tests is an option. On the other hand getting an RC to build is 
 pretty difficult ( I am facing the same problem with 6.6.1 ) and I am sure 
 people will run into this while voting for the release?
 
 We could identify the top 2/3 tests which fail regularly while building 
 the RC and either disable them or see if someone volunteers to fix them ?
 
 On Tue, Aug 29, 2017 at 2:53 AM, Ishan Chattopadhyaya 
 > wrote:
 > Those flaky Solr tests are annoying since people will also run into 
 > failures when
 > checking the RC? Should we disable these tests on the 7.0 branch so that 
 > building
 > and verifying this RC isn't annoying to everybody working on this 
 > release?
 
 +1. If it is hampering the release process, I think we should either not 
 release without fixing them, or disable them for release (building, 
 verifying).
 
 On Mon, Aug 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+181) - Build # 20504 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20504/
Java: 32bit/jdk-9-ea+181 -client -XX:+UseG1GC --illegal-access=deny

All tests passed

Build Log:
[...truncated 13625 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/temp/junit4-J2-20170920_125141_5456419816283003250174.sysout
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps/java_pid7604.hprof 
...
   [junit4] Heap dump file created [322566783 bytes in 0.538 secs]
   [junit4] <<< JVM J2: EOF 

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

Total time: 69 minutes 31 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Created] (LUCENE-7973) Update dictionary version for Urainian analyzer

[Andriy Rysin (JIRA)]

Andriy Rysin created LUCENE-7973:


 Summary: Update dictionary version for Urainian analyzer
 Key: LUCENE-7973
 URL: https://issues.apache.org/jira/browse/LUCENE-7973
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Andriy Rysin


Update morfologik dictionary version to 3.9.0 for Ukrainian analyzer.
There's 60K of new lemmas there along with some other improvements and fixes, 
particularly Ukrainian town names have been synchronized with official standard.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-7951:
--

The problem is that in the test you do not have information of the circle, you 
are just ask to create a point with a distance to another point at a bearing 
angle. 

I understand that the Geo3dShape is an ellipse as similar as possible to the 
circle. I wonder if you consider that the distance is the circle to consider, 
is possible to compute the error for the angle? 

> New wrapper classes for Geo3d
> -
>
> Key: LUCENE-7951
> URL: https://issues.apache.org/jira/browse/LUCENE-7951
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial-extras
>Reporter: Ignacio Vera
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, 
> LUCENE-7951.patch, LUCENE-7951.patch
>
>
> Hi,
> After the latest developments in the Geo3d library, in particular:
> [https://issues.apache.org/jira/browse/LUCENE-7906] : Spatial relationships 
> between GeoShapes
> [https://issues.apache.org/jira/browse/LUCENE-7936]: Serialization of 
> GeoShapes.
> I propose a new set of wrapper classes which can be for example linked to 
> Solr as they implement their own SpatialContextFactory. It provides the 
> capability of indexing shapes with 
>  spherical geometry.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testPoissonDistribution

Error Message:
expected:<100.023801> but was:<97.01113467346703>

Stack Trace:
java.lang.AssertionError: expected:<100.023801> but 
was:<97.01113467346703>
at 
__randomizedtesting.SeedInfo.seed([AC28C41B6210D2AA:34383BBAC0A9AAD6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:443)
at org.junit.Assert.assertEquals(Assert.java:512)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testPoissonDistribution(StreamExpressionTest.java:6318)
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 14429 lines...]
   [junit4] Suite: 

Re: Release 7.0 process starts

[Jan Høydahl]

Ok, so I took the liberty of updating 
https://wiki.apache.org/solr/ReleaseNote70 
 with my changes
Note that the previous version of the release notes can still be found at 
https://wiki.apache.org/solr/ReleaseNote70?action=info 
 for reference

Joel, look at the bullet I re-added about Math expressions, feel free to jump 
in and modify now that it is in the Wiki.

Cassandra, I totally agree about ref guide syncing and communicating one 
message.
Also the practice of listing some of the major features introduced in 6.x is a 
good thing.
If you have wording improvements to my summaries, please chime in, I’m not a 
technical writer :)

And please, I was serious about choosing 7 major features and not adding random 
single improvements. The list has already creeped from 7 to 9 bullets. If you 
want to add something, then ask youself which of the other bullets that are 
less important to MOST USERS and then replace that bullet instead of adding 
more. Agree?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 20. sep. 2017 kl. 14.34 skrev Joel Bernstein :
> 
> Hi Jan,
> 
> I added a note for Streaming Expressions in the comments. Could you add that 
> to the release notes?
> 
> 
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Wed, Sep 20, 2017 at 8:17 AM, David Smiley  > wrote:
> Excellent Jan!  Editorial summaries should be the standard our users expect.
> 
> 
> On Wed, Sep 20, 2017 at 7:51 AM Jan Høydahl  > wrote:
> I think the (Solr) release notes feels more like a dump of JIRA descriptions 
> than an editorial summary of main highlights.
> People who want to dive deep can read CHANGES, let’s choose top-7 largest 
> changes, describe them editorially and refer to CHANGES for the rest 
> including upgrade notes?
> 
> I made a total re-write here 
> https://gist.github.com/3afd5095834ee9e5d60b2eb304c21bec 
>  including a 
> general warning at the end that this is a major release that removes 
> deprecated stuff and that you should read the upgrade notes.
> Anshum, feel free to disagree and discard or use at will!
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 19. sep. 2017 kl. 22.44 skrev Anshum Gupta > >:
>> 
>> Please find the release notes here:
>> 
>> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote70 
>> 
>> 
>> Solr: https://wiki.apache.org/solr/ReleaseNote70 
>>  
>> 
>> I am cleaning up the ‘upgrading from 6x’ section to make it shorter but feel 
>> free to either fix/add things to this. I pushed the artifacts last night so 
>> there are still about 8 hours to the 24 hours period. 
>> 
>> I’ll use the 8 hours to fix the website etc. and announce once all of this 
>> is wrapped up!
>> 
>> -Anshum
>> 
>> 
>> 
>>> On Aug 28, 2017, at 10:46 PM, Varun Thacker >> > wrote:
>>> 
>>> I don't think holding up the release process infinitely till we stabilize 
>>> all the tests is an option. On the other hand getting an RC to build is 
>>> pretty difficult ( I am facing the same problem with 6.6.1 ) and I am sure 
>>> people will run into this while voting for the release?
>>> 
>>> We could identify the top 2/3 tests which fail regularly while building the 
>>> RC and either disable them or see if someone volunteers to fix them ?
>>> 
>>> On Tue, Aug 29, 2017 at 2:53 AM, Ishan Chattopadhyaya 
>>> > wrote:
>>> > Those flaky Solr tests are annoying since people will also run into 
>>> > failures when
>>> > checking the RC? Should we disable these tests on the 7.0 branch so that 
>>> > building
>>> > and verifying this RC isn't annoying to everybody working on this release?
>>> 
>>> +1. If it is hampering the release process, I think we should either not 
>>> release without fixing them, or disable them for release (building, 
>>> verifying).
>>> 
>>> On Mon, Aug 28, 2017 at 11:47 PM, Anshum Gupta >> > wrote:
>>> Though those failing tests are annoying, I would not recommend ignoring 
>>> those tests. We can manually ignore those test failures when we are testing 
>>> stuff out though.
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
 On Aug 28, 2017, at 11:10 AM, Adrien Grand > wrote:
 
 Those flaky Solr tests are annoying since people will also run into 
 failures when checking the RC? Should we disable these tests on the 7.0