[JENKINS-EA] Lucene-Solr-7.x-Windows (64bit/jdk-9-ea+173) - Build # 8 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/8/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrBootstrapTest.testConvertClusterToCdcrAndBootstrap

Error Message:
Document mismatch on target after sync expected:<1000> but was:<0>

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<1000> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([56CFA63407297146:81188943B376E901]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.CdcrBootstrapTest.testConvertClusterToCdcrAndBootstrap(CdcrBootstrapTest.java:134)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.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:  junit.framework.TestSuite.org.apache.solr.search.TestSearcherReuse

Error Message:

[jira] [Commented] (SOLR-11011) Assign.buildCoreName can lead to error in creating a new core when legacyCloud=false

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11011:
--

Nice Dat! Although this was caught while testing {{autoAddReplicasPlanAction}} 
for autoscaling, it can happen today in the wild if a user uses the 
DELETEREPLICA or MOVEREPLICA or REPLACENODE API to delete replicas and then a 
new replica is created on the same node with the same core name.

> Assign.buildCoreName can lead to error in creating a new core when 
> legacyCloud=false
> 
>
> Key: SOLR-11011
> URL: https://issues.apache.org/jira/browse/SOLR-11011
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>
> Here are the case
> {code}
> shard1 : {
> node1 : shard1_replica1,
> node2 : shard1_replica2
> }
> {code}
> node2 go down, autoAddReplicasPlanAction is executed
> {code}
> shard1 : {
> node1 : shard1_replica1,
> node3 : shard1_replica3
> }
> {code}
> node2 back alive, because shard1_replica2 is removed from {{states.json}} so 
> that core won't be loaded ( but it won't be removed neither ). Then node1 go 
> down, Assign.buildCoreName will create a core with name=shard1_replica2 which 
> lead to a failure.



--
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-NightlyTests-7.x - Build # 2 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/2/

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsUnloadDistributedZkTest.test

Error Message:
Could not find collection : unloadcollection

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : 
unloadcollection
at 
__randomizedtesting.SeedInfo.seed([4326C8729C267E15:CB72F7A832DA13ED]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.testCoreUnloadAndLeaders(UnloadDistributedZkTest.java:177)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.test(UnloadDistributedZkTest.java:67)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

Re: JCC Segfault on Debian 9 (stretch)

[Andi Vajda]

> On Jul 6, 2017, at 00:03, Joshua Campbell  wrote:
> 
> I confirmed that it crashes on multiple Debian 9 machines but it
> doesn't crash on Ubuntu 16.04. This behavior is consistent regardless
> of the JDK used (I tried openjdk 8, oracle 8 and openjdk 9). I am at a
> loss for how to track it down further due to the (apparent) GDB bug.

Hmmm, maybe JNI is broken on Debian 9 ?

Andi..

> 
>> On Wed, Jul 5, 2017 at 2:39 PM, Joshua Campbell  wrote:
>> No, it segfaults.
>> 
>>> On Wed, Jul 5, 2017 at 2:26 PM, Andi Vajda  wrote:
>>> 
 On Jul 5, 2017, at 22:16, Joshua Campbell  wrote:
 
 It's occuring after JCC calls JNI_CreateJavaVM
 
 cpp.py(529): env = initVM(os.pathsep.join(classpath) or None, 
 **initvm_args)
 ^ last python trace before death
 
 Breakpoint 5, initVM (self=0x77e05048, args=0x766deac8,
   kwds=0x77e00ec8) at jcc3/sources/jcc.cpp:527
 527 if (JNI_CreateJavaVM(, (void **) _env, _args) < 0)
  last line of jcc.cpp before death
 
 (gdb) step
 
 Program received signal SIGSEGV, Segmentation fault.
 0x7fffe43942b4 in ?? ()
 (gdb)
 
 
 AFTER fixing debians debugging symbols with ln -s
 /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64
 /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64
 
 Breakpoint 1, JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418,
   args=0x7fffc450) at ./src/hotspot/src/share/vm/prims/jni.cpp:5161
 5161./src/hotspot/src/share/vm/prims/jni.cpp: No such file or 
 directory.
 (gdb) s
 JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418, 
 args=0x7fffc450)
   at ./src/hotspot/src/share/vm/prims/jni.cpp:5163
 5163in ./src/hotspot/src/share/vm/prims/jni.cpp
 (gdb)
 /build/gdb-A87voC/gdb-7.12/gdb/inline-frame.c:167: internal-error:
 void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion
 `frame_id_p (*this_id)' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) n
 
 This is a bug, please report it.  For instructions, see:
 .
 
 What in the name of heck
>>> 
>>> Does it run without gdb ?
>>> 
>>> Andi..
>>> 
 
 On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell  
 wrote:
>> But you should get a better stacktrace ?
> 
> I got the exact same stacktrace.
> 
> $ ldd
> venv3/lib/python3.5/site-packages/JCC-3.0-py3.5-linux-x86_64.egg/libjcc3.so
>   linux-vdso.so.1 (0x7ffcf4eb8000)
>   libjava.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
> (0x7f412227f000)
>   libjvm.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
> (0x7f412133d000)
>   libpython3.5m.so.1.0 =>
> /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 (0x7f4120c3a000)
>   libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f41208b8000)
>   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f41205b4000)
>   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f412039b000)
>   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f412017e000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f411fddf000)
>   libverify.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libverify.so
> (0x7f411fbce000)
>   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f411f9ca000)
>   libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
> (0x7f411f7a)
>   libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f411f584000)
>   libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
> (0x7f411f381000)
>   /lib64/ld-linux-x86-64.so.2 (0x55857b9dd000)
> 
> I did verify it's compiling with -g
> 
> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -g
> -fdebug-prefix-map=/build/python3.5-MLq5fN/python3.5-3.5.3=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -fPIC -g -D_java_generics -DJCC_VER="3.0"
> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include
> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux -I_jcc3 
> -Ijcc3/sources
> -I/usr/include/python3.5m
> -I/home/joshua/unnaturalcode/venv3/include/python3.5m -c
> _jcc3/java/lang/String.cpp -o
> build/temp.linux-x86_64-3.5/_jcc3/java/lang/String.o -DPYTHON
> -fno-strict-aliasing -Wno-write-strings -O0 -g -DDEBUG
> 
> But it's still producing
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffe47eb2b4 in ?? ()

Re: Fix versions

[Anshum Gupta]

Thanks for the insight hoss :). I agree that I went into this with my 
assumptions.

>  A user who sees that a bug is fixed in "6.6.1" has no way to be 
> confident that the same bug is fixed in "7.0" just because the major 
> number is greater -- because we might releast 6.6.1 after 7.0 is released.  

The only way to confidently look at the information on the JIRA and comment on 
what versions have a particular feature/bug/fix is through a combination of 
“Affected Versions” and “fixVersions”. As David mentioned, there isn’t a single 
true ‘solution’ for this problem so the more information we provide the better.

In what I am proposing, I am certainly resting the responsibility of providing 
all of that information ‘correctly’ to the users on the committer/developer. 
So, missing a commit, and/or fixVersion certainly does mess things up. Also, 
the non-linear releases that we have make it confusing for anyone who isn’t 
aware of the order of releases.

I just wanted to highlight what I thought was missing information and I’d be 
happy to have an entry-per-commit as long as we think that’s the most 
reasonable available option. 

I am also not sure how adding “Affected Version” would completely help with 
mitigating problems like - ‘x’ was fixed in 7.2.0, 7.1.1, 7.0.2, and 6.6.3, but 
"affects versions” 7.1.0, 7.0.1, 6.6.2, and 6.5”.

If it was a known issue in 6.4,6.3, etc. it would 1. require the developer to 
figure out, and provide that information, and 2. Enlist all of those versions, 
which might get a little too much.

I don’t want to spiral this discussion and spin it off into a never ending one 
so whatever we all agree with, I’ll be more than happy to move ahead with it.

-Anshum



> On Jul 5, 2017, at 6:42 PM, Chris Hostetter  wrote:
> 
> 
> : Here’s my issue with that approach. Say I commit something that would be 
> : released with 7.0 but obviously, I also commit to master at this point. 
> : Going with your approach here are the fix versions I’ll end up with on 
> : the JIRA - master (8.0), 7.1, and 7.0.
> : 
> : This confuses me, as anything that has a 7.0 fix version shouldn’t have 
> : anything else from the 7x line. Also, it shouldn’t have anything from a 
> : line greater than that i.e. master (8.0) as it is obvious to me that 
> : there can not be any fix that makes it’s way into 7.0 but not 7.1, or 
> : 8.0.
> 
> The problem(s) with your "obvious" assertion are:
> 
> 1) just because it's "obvious" to you doesn't mean it's obvious to 
> everyone.  A user who sees that a bug is fixed in "6.6.1" has no way to be 
> confident that the same bug is fixed in "7.0" just because the major 
> number is greater -- because we might releast 6.6.1 after 7.0 is released.  
> To you and I it's obvious that's a diff situation from your "8.0 vs 7.1 vs 
> 7.0" example -- but only because we know how the branches are used and 
> forked off of eachother.  If you tell a user "any bug fiexed in 7.0.0 is 
> by definition also fixed in 7.1.0" it is understandable for them to 
> extrapolate that "any bug fixed in 7.0.1 is also fixed in 7.1.0"
> 
> 2) It is in fact very possible for human error to result in a bug fix 
> making it's way into 7.0.0, but not into 7.1.0 when (as they are today, 
> post branch_7_0 creation) 2 distinct commits/merges are needed to 2 
> distinct branches.  a philosophy of "each branch changed == a fixVersion 
> added" helps developers sanity check their own actions vs their 
> expectations, and gives people watching jiras enough info to sanity 
> check a committers actions even if they don't understand the specifics of 
> the affected code...
> 
> If you commit a bug fix to your local branch_7x and branch_7_0, but 
> something goes wrong with your push to branch_7x (perhaps a conflict 
> because someone else has added a feature to that branch since your last 
> merge/rebase) and you don't notice, people watching the issue who see a 
> single commit to branch_7_0 and you setting the fixVersion=7.0 might 
> easily assume the "bug" only affects the 7.0 release line, and doesn't 
> exist in branch_7x due to other changes.  If you explicitly set 
> fixVersion="7.0, 7.(x|1)" but there is only 1 commit to branch_7_0 for 
> that jira, then hopefully that raises eyebrows from other people who can 
> ask you about it and help you catch your mistake.
> 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> 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 # 7 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testNoSslButSillyClientAuth

Error Message:
Could not find collection:second_collection

Stack Trace:
java.lang.AssertionError: Could not find collection:second_collection
at 
__randomizedtesting.SeedInfo.seed([969706939A6DB1F3:FBC1B22D7EE4121E]: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.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:202)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:188)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:138)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testNoSslButSillyClientAuth(TestMiniSolrCloudClusterSSL.java:103)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

Re: Fix versions

[Chris Hostetter]

: Here’s my issue with that approach. Say I commit something that would be 
: released with 7.0 but obviously, I also commit to master at this point. 
: Going with your approach here are the fix versions I’ll end up with on 
: the JIRA - master (8.0), 7.1, and 7.0.
: 
: This confuses me, as anything that has a 7.0 fix version shouldn’t have 
: anything else from the 7x line. Also, it shouldn’t have anything from a 
: line greater than that i.e. master (8.0) as it is obvious to me that 
: there can not be any fix that makes it’s way into 7.0 but not 7.1, or 
: 8.0.

The problem(s) with your "obvious" assertion are:

1) just because it's "obvious" to you doesn't mean it's obvious to 
everyone.  A user who sees that a bug is fixed in "6.6.1" has no way to be 
confident that the same bug is fixed in "7.0" just because the major 
number is greater -- because we might releast 6.6.1 after 7.0 is released.  
To you and I it's obvious that's a diff situation from your "8.0 vs 7.1 vs 
7.0" example -- but only because we know how the branches are used and 
forked off of eachother.  If you tell a user "any bug fiexed in 7.0.0 is 
by definition also fixed in 7.1.0" it is understandable for them to 
extrapolate that "any bug fixed in 7.0.1 is also fixed in 7.1.0"

2) It is in fact very possible for human error to result in a bug fix 
making it's way into 7.0.0, but not into 7.1.0 when (as they are today, 
post branch_7_0 creation) 2 distinct commits/merges are needed to 2 
distinct branches.  a philosophy of "each branch changed == a fixVersion 
added" helps developers sanity check their own actions vs their 
expectations, and gives people watching jiras enough info to sanity 
check a committers actions even if they don't understand the specifics of 
the affected code...

If you commit a bug fix to your local branch_7x and branch_7_0, but 
something goes wrong with your push to branch_7x (perhaps a conflict 
because someone else has added a feature to that branch since your last 
merge/rebase) and you don't notice, people watching the issue who see a 
single commit to branch_7_0 and you setting the fixVersion=7.0 might 
easily assume the "bug" only affects the 7.0 release line, and doesn't 
exist in branch_7x due to other changes.  If you explicitly set 
fixVersion="7.0, 7.(x|1)" but there is only 1 commit to branch_7_0 for 
that jira, then hopefully that raises eyebrows from other people who can 
ask you about it and help you catch your mistake.


-Hoss
http://www.lucidworks.com/

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: withShardField
at 
__randomizedtesting.SeedInfo.seed([EF66849CF72C37F:5BA680DB638B0C8F]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1139)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:822)
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.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter(CustomCollectionTest.java:141)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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)

Re: Why Does Smoke Tester Fail with Ant 1.10?

[Chris Hostetter]

: I think my confusion stems from the smoke checker allowing ant 1.8 OR 1.9,
: then.
: 
https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/smokeTestRelease.py#L193

That seems bad to me - the explicit check for the minimum version of ant 
(used to make the jars) is suppose to be deliberate (as Uwe pointed out)

Mike: do you remember why you made this change

https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=6dfe73d5fe28dd53f251040df4514fd9c84f3ab6


: Unless there's another place where the build fails with 1.9 that I didn't
: see?
: 
: The release wiki does explicitly mention ant 1.8.x, so there is some
: mention of the requirement, but it also reads like it might be an old
: requirement that was never updated.
: https://wiki.apache.org/lucene-java/ReleaseTodo
: 
: On Sun, Jul 2, 2017, 2:19 AM Uwe Schindler  wrote:
: 
: > Hi,
: >
: >
: >
: > as said in my previous mail, the release is always done using the minimum
: > versions. The reason for this is (especially regarding Java version):
: >
: >
: >
: > The JAR files have to be compiled using the minimum Java version. This is
: > also required by Oracle’s guidelines, because otherwise they can’t
: > guarantee that the release also works with the source/target version. So
: > giving source/target is not enough. This will change with Java 9, where you
: > can give a new parameter “-release 8” that also compiles against the old
: > symbols. Lucene already uses this when building with Java 9.
: >
: >
: >
: > So it is important that a release of Lucene 5 is done with Java 7 and
: > nothing else, and a release of Lucene 6 or 7 needs to be done with Java 8.
: > Smoketester verifies this in the resulting JAR files (the META-INF folder
: > must contain right version numbers).
: >
: >
: >
: > About “Ant” we do the same, although this requirement is more
: > questionable. The reason is: Everything else in Lucene’s build has fixed
: > versions from Maven Central, just Java version and Ant version is coming
: > from RM’s local machine. So we want to also use the “minimum” version here
: > – at least for a release, so smoker checks this. This also guarantees that
: > anybody can at least use the minimum version to build Lucene and Solr.
: >
: >
: >
: > I don’t think it’s a complicated requirement for the RM to download the
: > ANT zip file and place it in his home dir! I have a separate user account
: > for this that I SSH in when doing a release. Jenkins is doing something
: > similar: It just uses the right Ant version (1.8.2) with an absolute path.
: >
: >
: >
: > BTW: In Gradle this is similar, you use the Gradle-Wrapper to make
: > repeatable builds with exact versions! Ant just has no “ant wrapper” 
: >
: >
: >
: > Uwe
: >
: >
: >
: > -
: >
: > Uwe Schindler
: >
: > Achterdiek 19, D-28357 Bremen
: >
: > http://www.thetaphi.de
: >
: > eMail: u...@thetaphi.de
: >
: >
: >
: > *From:* Mike Drob [mailto:md...@apache.org]
: > *Sent:* Sunday, July 2, 2017 7:15 AM
: > *To:* dev@lucene.apache.org
: > *Subject:* Re: Why Does Smoke Tester Fail with Ant 1.10?
: >
: >
: >
: > Where is the official ant version specified?
: >
: >
: >
: > https://github.com/apache/lucene-solr/blob/master/lucene/BUILD.txt gives
: > a minimum version, but not a single version.
: >
: >
: >
: > Same for Java, actually.
: >
: > On Sat, Jul 1, 2017, 6:28 PM Uwe Schindler  wrote:
: >
: > Hi,
: >
: >
: >
: > The reason for the failure is that „nightly smoke“ emulates a release. And
: > for releases we require the release manager to use:
: >
: >- exactly the Java version that the release is intended for (e.g., you
: >cannot make a 6.x release with Java 9)
: >- the offcial Ant version
: >
: >
: >
: > The reason for these limitations is reproducibility of releases and to
: > prevent bugs that might appear without our knowledge.
: >
: >
: >
: > Uwe
: >
: >
: >
: > -
: >
: > Uwe Schindler
: >
: > Achterdiek 19, D-28357 Bremen
: >
: > http://www.thetaphi.de
: >
: > eMail: u...@thetaphi.de
: >
: >
: >
: > *From:* md...@cloudera.com [mailto:md...@cloudera.com] *On Behalf Of *Mike
: > Drob
: > *Sent:* Sunday, July 2, 2017 1:22 AM
: > *To:* Lucene Dev 
: > *Subject:* Why Does Smoke Tester Fail with Ant 1.10?
: >
: >
: >
: > Hi,
: >
: >
: >
: > I was recently running ant nightly-smoke and it failed because my version
: > of ant is too new. The default installed by homebrew is 1.10.1, while the
: > smoke test expects ant 1.8 or 1.9, looks like.
: >
: >
: >
: > Searching for ant 1.10 on the dev list gives me tons of false positives
: > (every jenkins failure, basically) so I have no idea if this has been
: > discussed or not.
: >
: >
: >
: > Is the ant version requirement a minimum (1.8+) that was too narrowly
: > implemented or a specific range due to some known issue in later ant
: > versions?
: >
: >
: >
: > Thanks,
: >
: > Mike
: >
: >
: 

-Hoss
http://www.lucidworks.com/

[jira] [Updated] (SOLR-11016) TestCloudJSONFacetJoinDomain.testBespoke() failures

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-11016:

Attachment: SOLR-11016.patch

Silly test bug -- the helper methods for verifying the facet results don't 
account for the possibility that the query won't match any (of the randomly 
indexed) documents.

Attached patch was generated from master, but also applies cleanly to 6x where 
I verified it fixes the mentioned seed failures.  It also includes some new 
"bespoke" queries that force issues like this to crop up regardless of the seed.

I'll hammer on this on master for a bit & then commit & backport to 7x

> TestCloudJSONFacetJoinDomain.testBespoke() failures
> ---
>
> Key: SOLR-11016
> URL: https://issues.apache.org/jira/browse/SOLR-11016
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11016.patch
>
>
> Policeman Jenkins found a reproducing branch_6x seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/980/]:
> {noformat}
> Checking out Revision 9947a811e83cc0f848f9ddaa37a4137f19efff1a 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestCloudJSONFacetJoinDomain -Dtests.method=testBespoke 
> -Dtests.seed=CF428F9440CE16E -Dtests.slow=true -Dtests.locale=cs 
> -Dtests.timezone=America/Aruba -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.72s J1 | TestCloudJSONFacetJoinDomain.testBespoke <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> {main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
>  ===> 
> {responseHeader={zkConnected=true,status=0,QTime=5},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
>  --> top key missing from: {count=0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([CF428F9440CE16E:72FACC08C8C2699]:0)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]> Caused by: java.lang.AssertionError: top key missing from: 
> {count=0}
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:351)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:331)
> [...]
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=RandomSimilarity(queryNorm=true,coord=crazy): {}, locale=cs, 
> timezone=America/Aruba
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_131 
> (64-bit)/cpus=3,threads=1,free=58802776,total=266338304
> {noformat}
> Another reproducing branch_6x seed, from 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/849/] (job history 
> has been removed since it's too old - notification email arrived on May 24th):
> {noformat}
> Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC
> 1 tests failed.
> FAILED:  org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke
> Error Message:
> {main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
>  ===> 
> {responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
>  --> top key missing from: {count=0}
> Stack Trace:
> java.lang.AssertionError: 
> {main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
>  ===> 
> {responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
>  --> top key missing from: {count=0}
>   at 
> __randomizedtesting.SeedInfo.seed([D2F19637CE167869:D92A120E0696BF9E]:0)
>   at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
>   at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
> {noformat}
> Note that both of the above seeds reproduce for me on Linux with Java8.



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

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

[jira] [Assigned] (SOLR-11016) TestCloudJSONFacetJoinDomain.testBespoke() failures

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-11016:
---

Assignee: Hoss Man

> TestCloudJSONFacetJoinDomain.testBespoke() failures
> ---
>
> Key: SOLR-11016
> URL: https://issues.apache.org/jira/browse/SOLR-11016
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Hoss Man
> Attachments: SOLR-11016.patch
>
>
> Policeman Jenkins found a reproducing branch_6x seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/980/]:
> {noformat}
> Checking out Revision 9947a811e83cc0f848f9ddaa37a4137f19efff1a 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestCloudJSONFacetJoinDomain -Dtests.method=testBespoke 
> -Dtests.seed=CF428F9440CE16E -Dtests.slow=true -Dtests.locale=cs 
> -Dtests.timezone=America/Aruba -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.72s J1 | TestCloudJSONFacetJoinDomain.testBespoke <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> {main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
>  ===> 
> {responseHeader={zkConnected=true,status=0,QTime=5},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
>  --> top key missing from: {count=0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([CF428F9440CE16E:72FACC08C8C2699]:0)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]> Caused by: java.lang.AssertionError: top key missing from: 
> {count=0}
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:351)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:331)
> [...]
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=RandomSimilarity(queryNorm=true,coord=crazy): {}, locale=cs, 
> timezone=America/Aruba
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_131 
> (64-bit)/cpus=3,threads=1,free=58802776,total=266338304
> {noformat}
> Another reproducing branch_6x seed, from 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/849/] (job history 
> has been removed since it's too old - notification email arrived on May 24th):
> {noformat}
> Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC
> 1 tests failed.
> FAILED:  org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke
> Error Message:
> {main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
>  ===> 
> {responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
>  --> top key missing from: {count=0}
> Stack Trace:
> java.lang.AssertionError: 
> {main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
>  ===> 
> {responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
>  --> top key missing from: {count=0}
>   at 
> __randomizedtesting.SeedInfo.seed([D2F19637CE167869:D92A120E0696BF9E]:0)
>   at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
>   at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
> {noformat}
> Note that both of the above seeds reproduce for me on Linux with Java8.



--
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-10726) SolrCloud opens multiple searchers on replica creation/startup

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10726:

Attachment: SOLR-10726.semaphore.newsearcher.test.patch
semaphore.newsearcher.test.log.txt


FWIW...

I was attempting to write a test that would prove/disprove if waitSearcher=true 
actually worked in SolrCloud, by having a 'newSearcher' event listener that 
used a semaphore to try and detect if/when a newSearcher was being warmed after 
the client's commit call had already been returned.

I ran into some weird problems, and in mentioning them in passing to shalin, he 
pointed me to this jira.

I'm attaching a patch showing what i have at the moment -- it doesn't really do 
much towards my current goal, but it does help demonstrate a few weird things 
about when/how newSerchers are being opened in SolrCloud that seems relevant to 
the related problems shalin mentioned when creating this jira...

* I had to put some special code in to do an initial commit (on the empty 
index) to work around the fact that evidently SolrCore will re-open a 
newSearcher after the very first commit -- even if no documents have been added 
to it's index.
** BUT: This doesn't happen on _every_ SolrCore ??? ... it seems to be an "N-1" 
situation, where N is the total number of cores.  Ie: in a 2 shard collection 
with repFactor=2, aparently only 3 of the cores open a newSearcher on this 
(empty) commit
** see the usage of {{nocommit_HACK_ON_HACK_nocommit_seriously_nocommit}} for 
details
* Once the test actaully starts adding docs to the index, things work 
predictible -- for a bit...
** The test sequentially does an add followed by a commit, and verifies (using 
the semaphore) that only 2 replicas (presumably of the shard the added document 
belongs to) open a newSearcher
** in reality, eventually a commit happens where every SolrCore re-opens a 
newSearcher (even though nothing in the index has changed on the 2 nodes of the 
other shards) and there aren't evenough permits in the semaphore.




I'm not planning to pursue this at the moment, but i wanted to share it in case 
it can serve as a useful starting point for anyone else who wants to look into 
figuring out why it's happening and/or reducing how often SolrCloud is opening 
newSearchers.


> SolrCloud opens multiple searchers on replica creation/startup
> --
>
> Key: SOLR-10726
> URL: https://issues.apache.org/jira/browse/SOLR-10726
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search, SolrCloud
>Affects Versions: 6.5.1
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-medium, impact-high
> Attachments: semaphore.newsearcher.test.log.txt, 
> SOLR-10726.semaphore.newsearcher.test.patch
>
>
> I was investigating some curious behavior reported by a customer around first 
> searcher event listeners and multiple searchers being opened when adding a 
> new replica.
> Turns out that if you add a new replica to solrcloud:
> 1) Searchers are opened at least twice and possibly a third time
> 2) the first time is because of a new core coming online and opening searcher 
> on an empty index -- only firstSearcher event listeners are fired here
> 3) second time is after replication is complete and we have new index files 
> available -- firstSearcher event listeners are fired again because the old 
> searcher opened on core load has already been closed and disposed so this is 
> technically again a first searcher
> 4) third time happens after documents buffered during recovery are replayed 
> -- if there was no indexing happening on leader then this step is skipped -- 
> a newSearcher event is fired here because we had already opened a searcher in 
> the last step
> Now if instead of a new replica, a solr node is restarted then there can be 
> upto four searcher opens -- the additional open is because of log replay on 
> startup.
> So Solr spends a lot of time on unnecessary warming/autowarming on searchers 
> that are discarded. It is not just warming because sometimes plugins such as 
> SpellCheckComponent and SuggestComponent can also tie in to these listener 
> events.
> We can probably cut a few of them or at least defer the decision of whether 
> to fire these listeners to places such as RecoveryStrategy which have a 
> better idea of whether it is worth 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] [Commented] (SOLR-10983) Fix DOWNNODE -> queue-work explosion

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-10983:
---

BTW: this issue most likely affects all 6.x releases (and even some late 5.x), 
so it should be considered if we do any 6.x point releases later.

> Fix DOWNNODE -> queue-work explosion
> 
>
> Key: SOLR-10983
> URL: https://issues.apache.org/jira/browse/SOLR-10983
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Scott Blum
>Assignee: Scott Blum
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10983.patch
>
>
> Every DOWNNODE command enqueues N copies of itself into queue-work, where N 
> is number of collections affected by the DOWNNODE.
> This rarely matters in practice, because queue-work gets immediately dumped-- 
> however, if anything throws an exception (such as ZK bad version), we don't 
> clear queue-work.  Then the next time through the loop we run the expensive 
> DOWNNODE command potentially hundreds of times.



--
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-Windows (64bit/jdk1.8.0_131) - Build # 7 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([3FE54B5AAE00EF91:5D88B51B618E8FAF]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at 
org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter(MetricsHandlerTest.java:201)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 10889 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.MetricsHandlerTest
   [junit4]   2> Creating dataDir: 

[jira] [Resolved] (SOLR-10983) Fix DOWNNODE -> queue-work explosion

[Scott Blum (JIRA)]

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

Scott Blum resolved SOLR-10983.
---
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)
   7.0

> Fix DOWNNODE -> queue-work explosion
> 
>
> Key: SOLR-10983
> URL: https://issues.apache.org/jira/browse/SOLR-10983
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Scott Blum
>Assignee: Scott Blum
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10983.patch
>
>
> Every DOWNNODE command enqueues N copies of itself into queue-work, where N 
> is number of collections affected by the DOWNNODE.
> This rarely matters in practice, because queue-work gets immediately dumped-- 
> however, if anything throws an exception (such as ZK bad version), we don't 
> clear queue-work.  Then the next time through the loop we run the expensive 
> DOWNNODE command potentially hundreds of times.



--
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-10983) Fix DOWNNODE -> queue-work explosion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10983:


Commit 17245c2e5a93bca59572c09af78a6ad6045e75eb in lucene-solr's branch 
refs/heads/branch_7x from [~dragonsinth]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=17245c2 ]

SOLR-10983: Fix DOWNNODE -> queue-work explosion


> Fix DOWNNODE -> queue-work explosion
> 
>
> Key: SOLR-10983
> URL: https://issues.apache.org/jira/browse/SOLR-10983
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Scott Blum
>Assignee: Scott Blum
> Attachments: SOLR-10983.patch
>
>
> Every DOWNNODE command enqueues N copies of itself into queue-work, where N 
> is number of collections affected by the DOWNNODE.
> This rarely matters in practice, because queue-work gets immediately dumped-- 
> however, if anything throws an exception (such as ZK bad version), we don't 
> clear queue-work.  Then the next time through the loop we run the expensive 
> DOWNNODE command potentially hundreds of times.



--
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-10983) Fix DOWNNODE -> queue-work explosion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10983:


Commit 51638c09bf4f5457650ab40c60b5f98512f9ca1d in lucene-solr's branch 
refs/heads/branch_7_0 from [~dragonsinth]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=51638c0 ]

SOLR-10983: Fix DOWNNODE -> queue-work explosion


> Fix DOWNNODE -> queue-work explosion
> 
>
> Key: SOLR-10983
> URL: https://issues.apache.org/jira/browse/SOLR-10983
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Scott Blum
>Assignee: Scott Blum
> Attachments: SOLR-10983.patch
>
>
> Every DOWNNODE command enqueues N copies of itself into queue-work, where N 
> is number of collections affected by the DOWNNODE.
> This rarely matters in practice, because queue-work gets immediately dumped-- 
> however, if anything throws an exception (such as ZK bad version), we don't 
> clear queue-work.  Then the next time through the loop we run the expensive 
> DOWNNODE command potentially hundreds of times.



--
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-10983) Fix DOWNNODE -> queue-work explosion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10983:


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

SOLR-10983: Fix DOWNNODE -> queue-work explosion


> Fix DOWNNODE -> queue-work explosion
> 
>
> Key: SOLR-10983
> URL: https://issues.apache.org/jira/browse/SOLR-10983
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Scott Blum
>Assignee: Scott Blum
> Attachments: SOLR-10983.patch
>
>
> Every DOWNNODE command enqueues N copies of itself into queue-work, where N 
> is number of collections affected by the DOWNNODE.
> This rarely matters in practice, because queue-work gets immediately dumped-- 
> however, if anything throws an exception (such as ZK bad version), we don't 
> clear queue-work.  Then the next time through the loop we run the expensive 
> DOWNNODE command potentially hundreds of times.



--
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-10317) Solr Nightly Benchmarks

[Michael Sun (JIRA)]

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

Michael Sun commented on SOLR-10317:


[~vivek.nar...@uga.edu] I saw you made some good progress. Not sure what 
framework you decided to use. But if you wanted to use your own, make sure add 
CPU util metric in test result. You are welcome to use code in my patch for CPU 
measurement.



> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> SOLR-10317.patch, SOLR-10317.patch, solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
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-10317) Solr Nightly Benchmarks

[Michael Sun (JIRA)]

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

Michael Sun commented on SOLR-10317:


Just uploaded a second cut of Solr benchmark framework I built at work. In 
addition to object model, this patch has a working JSON facet benchmark using 
JMeter and measures CPU usage during benchmark. More importantly, the code for 
JMeter and CPU usage are easily reusable in other benchmarks.

As mentioned earlier, the idea of this framework is to avoid building a new 
framework for all Solr performance work of upcoming years, by carefully 
designed, extensible object model and reusable components. I am aware of 
several existing Solr benchmarks, inc. one actively being developed now. Any 
feedback is appreciated. 

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> SOLR-10317.patch, SOLR-10317.patch, solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
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-10317) Solr Nightly Benchmarks

[Michael Sun (JIRA)]

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

Michael Sun updated SOLR-10317:
---
Attachment: SOLR-10317.patch

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> SOLR-10317.patch, SOLR-10317.patch, solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
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-6513) Allow limits on SpanMultiTermQueryWrapper expansion

[Timothy M. Rodriguez (JIRA)]

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

Timothy M. Rodriguez commented on LUCENE-6513:
--

[~romseygeek] we've written a patch to solve this problem as well we've been 
meaning to share with the community.  It goes about the solution in a bit of a 
different way.  We'll try to get it up here in a day or two, though I'm not 
sure which approach will be preferable.

> Allow limits on SpanMultiTermQueryWrapper expansion
> ---
>
> Key: LUCENE-6513
> URL: https://issues.apache.org/jira/browse/LUCENE-6513
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-6513.patch, LUCENE-6513.patch, LUCENE-6513.patch
>
>
> SpanMultiTermQueryWrapper currently rewrites to a SpanOrQuery with as many 
> clauses as there are matching terms.  It would be nice to be able to limit 
> this in a slightly nicer way than using TopTerms, which for most queries just 
> translates to a lexicographical ordering.



--
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] [Closed] (SOLR-8495) Schemaless mode cannot index large text fields

[JIRA]

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

Jan Høydahl closed SOLR-8495.
-
Resolution: Duplicate

Closing as duplicate of SOLR-9526

> Schemaless mode cannot index large text fields
> --
>
> Key: SOLR-8495
> URL: https://issues.apache.org/jira/browse/SOLR-8495
> Project: Solr
>  Issue Type: Bug
>  Components: Data-driven Schema, Schema and Analysis
>Affects Versions: 4.10.4, 5.3.1, 5.4
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-easy, impact-medium
> Fix For: 6.0, 5.5
>
> Attachments: SOLR-8495.patch
>
>
> The schemaless mode by default indexes all string fields into an indexed 
> StrField which is limited to 32KB text. Anything larger than that leads to an 
> exception during analysis.
> {code}
> Caused by: java.lang.IllegalArgumentException: Document contains at least one 
> immense term in field="text" (whose UTF8 encoding is longer than the max 
> length 32766)
> {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

Re: Fix versions

[Anshum Gupta]

I’ve put this on a wiki page, and did that as a ‘trivial change’, which 
shouldn’t have triggered any emails to anyone other than Steve (sorry about 
that). I’m not sure how to have that as a permanent setting for this page 
though.

Anyone?

Here’s the page: https://wiki.apache.org/lucene-java/SettingFixVersions

-Anshum



> On Jul 5, 2017, at 3:10 PM, David Smiley  wrote:
> 
> This makes sense to me.  It's easy to forget this stuff though.  Perhaps we 
> can propose a policy, vote on it, and post it somewhere?  We could even do 
> this in the Wiki (MoinMoin) -- so create a page, put "Draft/Proposal" 
> prominently at the top, and then share a link.  Keep it particularly succinct 
> so it's easy to see what the essence is, and then only potentially later 
> decorate with tips & whatever else.  It'd be nice but not required to have 
> changes to this page (and some selected others) be auto-copied to the dev 
> list somehow, e.g. by having a special account, but not required.
> 
> On Wed, Jul 5, 2017 at 5:56 PM Anshum Gupta  > wrote:
> @Dawid: I remember that discussion, and I think things were fixed for the 
> issue back then.
> 
> My concern right now is that we will end up in a similar situation again with 
> everyone interpreting the fixVersion differently.
> 
> @Erick
> Here’s my issue with that approach. Say I commit something that would be 
> released with 7.0 but obviously, I also commit to master at this point. Going 
> with your approach here are the fix versions I’ll end up with on the JIRA - 
> master (8.0), 7.1, and 7.0. 
> 
> This confuses me, as anything that has a 7.0 fix version shouldn’t have 
> anything else from the 7x line. Also, it shouldn’t have anything from a line 
> greater than that i.e. master (8.0) as it is obvious to me that there can not 
> be any fix that makes it’s way into 7.0 but not 7.1, or 8.0.
> 
> Also, from my understanding, a fix version of 7.1 would mean that the first 
> time this was released on the 7x line was 7.1 (which wouldn’t be the case 
> here).
> 
> Yes, things would work differently for bug fix releases, but I’m talking 
> about the major release version here.
> 
> Here’s my suggestion:
> 
> - For a fix that will be released with a major version, just mention the 
> major version
> - For a minor version
>   - master (current version + 1)
>   - minor version release that would have this fix
>   - all prior bug fix releases, when this is back-ported to older branches
> - Bug fix release
>   - The only case when a fix is released with such a release, is when 
>   - The issue was introduced by a minor version release right 
> before this release AND
>   - There was no other minor/major release since this issue was 
> introduced.
>   - In such a case, the fix version should only have the bug fix version, 
> and not master, etc.
> 
> What would also be useful here is specifying the ‘Affects Version’ but in my 
> experience, this gets tough to figure at times for bug fixes, and doesn’t 
> generally make sense for new features/enhancements.
> 
> If there’s anything else, I’d be happy to just go with whatever everyone 
> wants to follow as long as it makes things easier to understand and manage. 
> 
> 
> -Anshum
> 
> 
> 
>> On Jul 5, 2017, at 2:13 PM, Erick Erickson > > wrote:
>> 
>> I'm just including a fix version for each push I make. I.e.
>> 
>> If I push to master I'll add "master (8.0)".
>> If I push to 7x, at this point I'll add 7.1
>> If I push to 7_0 I'll add 7.0
>> If I push to 6x I'll add 6.7
>> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
>> 
>> I think one push == one label is unambiguous. You do have to realize
>> that if there may never be, say, a 6.6.1 in my example. But we do
>> remove the onus of people having to figure out what a fix version of
>> plain "master" or "7x" means.
>> 
>> FWIW
>> Erick
>> 
>> 
>> 
>> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss > > wrote:
>>> There's been a fairly recent discussion about it on the mailing list
>>> (David Smiley and were involved in that discussion, among other
>>> people). There are many different takes on how to handle fix-for and
>>> branches. I don't think we can find the "best" strategy, although
>>> perhaps we can agree on something project-specific. I've expressed my
>>> opinion on that previous post, but I'm open to any strategy.
>>> 
>>> Dawid
>>> 
>>> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta >> > wrote:
 Hi,
 
 I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
 are being committed right now. I think it makes sense for the fixVersion to
 just be 7.0, and nothing else for everything that is going into branch_7_0,
 instead of being both 7.0, and 

[jira] [Commented] (SOLR-10123) Analytics Component 2.0

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10123:
-


bq. Houston is working on a new batch of tests that will specifically test the 
new analytics expression language. I'm going to wait until those are added (and 
checked) before merging this PR.

I haven't reviewed the patch in depth, but since it appears to fix some genuine 
bugs with point field handling (see changes to existing "instanceof TrieField") 
in addition to already improving the test coverage of points, i would urge you 
to commit ASAP if you think it's good enough -- a "bug fix with tests" patch 
shouldn't be blocked waiting on more tests.

bq. ...do you have any other concerns about this and/or possible ramifications 
of this change?

My chief concern was that points be tested if the new code was going to claim 
it works with points -- either that or file some "known issues" bugs 
documenting the problems and use \@SuppressPointFields to indicate them -- as 
opposed to how this issue currently exists on master: w/o any attempt at 
testing points at all.  If the tests already committed by this issue can be 
made to work with points by committing the PR, then i (personally) have no 
concerns

> Analytics Component 2.0
> ---
>
> Key: SOLR-10123
> URL: https://issues.apache.org/jira/browse/SOLR-10123
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Houston Putman
>  Labels: features
> Attachments: SOLR-10123.patch, SOLR-10123.patch, SOLR-10123.patch
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * New JSON request language, and response format that fits JSON better.
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
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: Fix versions

[Mike Drob]

This would be good to see as part of the How To Contribute guide, I think,
or at least linked from there.

On Wed, Jul 5, 2017 at 5:10 PM, David Smiley 
wrote:

> This makes sense to me.  It's easy to forget this stuff though.  Perhaps
> we can propose a policy, vote on it, and post it somewhere?  We could even
> do this in the Wiki (MoinMoin) -- so create a page, put "Draft/Proposal"
> prominently at the top, and then share a link.  Keep it particularly
> succinct so it's easy to see what the essence is, and then only potentially
> later decorate with tips & whatever else.  It'd be nice but not required to
> have changes to this page (and some selected others) be auto-copied to the
> dev list somehow, e.g. by having a special account, but not required.
>
> On Wed, Jul 5, 2017 at 5:56 PM Anshum Gupta  wrote:
>
>> @Dawid: I remember that discussion, and I think things were fixed for the
>> issue back then.
>>
>> My concern right now is that we will end up in a similar situation again
>> with everyone interpreting the fixVersion differently.
>>
>> @Erick
>> Here’s my issue with that approach. Say I commit something that would be
>> released with 7.0 but obviously, I also commit to master at this point.
>> Going with your approach here are the fix versions I’ll end up with on the
>> JIRA - *master (8.0), 7.1, and 7.0*.
>>
>> This confuses me, as anything that has a 7.0 fix version shouldn’t have
>> anything else from the 7x line. Also, it shouldn’t have anything from a
>> line greater than that i.e. master (8.0) as it is obvious to me that there
>> can not be any fix that makes it’s way into 7.0 but not 7.1, or 8.0.
>>
>> Also, from my understanding, a fix version of 7.1 would mean that the
>> first time this was released on the 7x line was 7.1 (which wouldn’t be the
>> case here).
>>
>> Yes, things would work differently for bug fix releases, but I’m talking
>> about the major release version here.
>>
>> Here’s my suggestion:
>>
>> - For a fix that will be released with a major version, just mention the
>> major version
>> - For a minor version
>> - master (current version + 1)
>> - minor version release that would have this fix
>> - all prior bug fix releases, when this is back-ported to older branches
>> - Bug fix release
>> - The only case when a fix is released with such a release, is when
>> - The issue was introduced by a minor version release right before this
>> release AND
>> - There was no other minor/major release since this issue was introduced.
>> - In such a case, the fix version should only have the bug fix version,
>> and not master, etc.
>>
>> What would also be useful here is specifying the ‘*Affects Version*’ but
>> in my experience, this gets tough to figure at times for bug fixes, and
>> doesn’t generally make sense for new features/enhancements.
>>
>> If there’s anything else, I’d be happy to just go with whatever everyone
>> wants to follow as long as it makes things easier to understand and manage.
>>
>>
>> -Anshum
>>
>>
>>
>> On Jul 5, 2017, at 2:13 PM, Erick Erickson 
>> wrote:
>>
>> I'm just including a fix version for each push I make. I.e.
>>
>> If I push to master I'll add "master (8.0)".
>> If I push to 7x, at this point I'll add 7.1
>> If I push to 7_0 I'll add 7.0
>> If I push to 6x I'll add 6.7
>> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
>>
>> I think one push == one label is unambiguous. You do have to realize
>> that if there may never be, say, a 6.6.1 in my example. But we do
>> remove the onus of people having to figure out what a fix version of
>> plain "master" or "7x" means.
>>
>> FWIW
>> Erick
>>
>>
>>
>> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss 
>> wrote:
>>
>> There's been a fairly recent discussion about it on the mailing list
>> (David Smiley and were involved in that discussion, among other
>> people). There are many different takes on how to handle fix-for and
>> branches. I don't think we can find the "best" strategy, although
>> perhaps we can agree on something project-specific. I've expressed my
>> opinion on that previous post, but I'm open to any strategy.
>>
>> Dawid
>>
>> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta  wrote:
>>
>> Hi,
>>
>> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
>> are being committed right now. I think it makes sense for the fixVersion
>> to
>> just be 7.0, and nothing else for everything that is going into
>> branch_7_0,
>> instead of being both 7.0, and master (8.0).
>>
>> Any thoughts?
>>
>> -Anshum
>>
>>
>>
>>
>> -
>> 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 

[jira] [Commented] (SOLR-11013) remove /v2/c alias in favour of /v2/collections only

[JIRA]

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

Jan Høydahl commented on SOLR-11013:


I think perhaps the collections endpoint is special, since it will be by far 
the most used, thus it warrants a shortcut in my mind. I don't want to type 
{{curl localhost:8983/v2/collections/mycoll/select?q=foo}} which is 10 
keystrokes more than needed with v1 api... With /v2/c it will remain same 
length as today. Let's instead remove the /v2/collections variant?

> remove /v2/c alias in favour of /v2/collections only
> 
>
> Key: SOLR-11013
> URL: https://issues.apache.org/jira/browse/SOLR-11013
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11013.patch
>
>
> (Perhaps this has already been considered previously elsewhere or on the 
> mailing list and I just missed it then and couldn't find it now, in which 
> case happy to withdraw this ticket.)
> Would like propose that {{/v2/c}} be removed in favour of {{/v2/collections}} 
> only:
> * there being two ways to do the same thing is potentially confusing
> * {{/v2/c}} is short but _c_ could stand not only for _collections_ but also 
> for _cores_ or _cluster_ or _config_ or _cloud_ etc.



--
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: Fix versions

[David Smiley]

This makes sense to me.  It's easy to forget this stuff though.  Perhaps we
can propose a policy, vote on it, and post it somewhere?  We could even do
this in the Wiki (MoinMoin) -- so create a page, put "Draft/Proposal"
prominently at the top, and then share a link.  Keep it particularly
succinct so it's easy to see what the essence is, and then only potentially
later decorate with tips & whatever else.  It'd be nice but not required to
have changes to this page (and some selected others) be auto-copied to the
dev list somehow, e.g. by having a special account, but not required.

On Wed, Jul 5, 2017 at 5:56 PM Anshum Gupta  wrote:

> @Dawid: I remember that discussion, and I think things were fixed for the
> issue back then.
>
> My concern right now is that we will end up in a similar situation again
> with everyone interpreting the fixVersion differently.
>
> @Erick
> Here’s my issue with that approach. Say I commit something that would be
> released with 7.0 but obviously, I also commit to master at this point.
> Going with your approach here are the fix versions I’ll end up with on the
> JIRA - *master (8.0), 7.1, and 7.0*.
>
> This confuses me, as anything that has a 7.0 fix version shouldn’t have
> anything else from the 7x line. Also, it shouldn’t have anything from a
> line greater than that i.e. master (8.0) as it is obvious to me that there
> can not be any fix that makes it’s way into 7.0 but not 7.1, or 8.0.
>
> Also, from my understanding, a fix version of 7.1 would mean that the
> first time this was released on the 7x line was 7.1 (which wouldn’t be the
> case here).
>
> Yes, things would work differently for bug fix releases, but I’m talking
> about the major release version here.
>
> Here’s my suggestion:
>
> - For a fix that will be released with a major version, just mention the
> major version
> - For a minor version
> - master (current version + 1)
> - minor version release that would have this fix
> - all prior bug fix releases, when this is back-ported to older branches
> - Bug fix release
> - The only case when a fix is released with such a release, is when
> - The issue was introduced by a minor version release right before this
> release AND
> - There was no other minor/major release since this issue was introduced.
> - In such a case, the fix version should only have the bug fix version,
> and not master, etc.
>
> What would also be useful here is specifying the ‘*Affects Version*’ but
> in my experience, this gets tough to figure at times for bug fixes, and
> doesn’t generally make sense for new features/enhancements.
>
> If there’s anything else, I’d be happy to just go with whatever everyone
> wants to follow as long as it makes things easier to understand and manage.
>
>
> -Anshum
>
>
>
> On Jul 5, 2017, at 2:13 PM, Erick Erickson 
> wrote:
>
> I'm just including a fix version for each push I make. I.e.
>
> If I push to master I'll add "master (8.0)".
> If I push to 7x, at this point I'll add 7.1
> If I push to 7_0 I'll add 7.0
> If I push to 6x I'll add 6.7
> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
>
> I think one push == one label is unambiguous. You do have to realize
> that if there may never be, say, a 6.6.1 in my example. But we do
> remove the onus of people having to figure out what a fix version of
> plain "master" or "7x" means.
>
> FWIW
> Erick
>
>
>
> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss  wrote:
>
> There's been a fairly recent discussion about it on the mailing list
> (David Smiley and were involved in that discussion, among other
> people). There are many different takes on how to handle fix-for and
> branches. I don't think we can find the "best" strategy, although
> perhaps we can agree on something project-specific. I've expressed my
> opinion on that previous post, but I'm open to any strategy.
>
> Dawid
>
> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta  wrote:
>
> Hi,
>
> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
> are being committed right now. I think it makes sense for the fixVersion to
> just be 7.0, and nothing else for everything that is going into branch_7_0,
> instead of being both 7.0, and master (8.0).
>
> Any thoughts?
>
> -Anshum
>
>
>
>
> -
> 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
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: JCC Segfault on Debian 9 (stretch)

[Joshua Campbell]

I confirmed that it crashes on multiple Debian 9 machines but it
doesn't crash on Ubuntu 16.04. This behavior is consistent regardless
of the JDK used (I tried openjdk 8, oracle 8 and openjdk 9). I am at a
loss for how to track it down further due to the (apparent) GDB bug.

On Wed, Jul 5, 2017 at 2:39 PM, Joshua Campbell  wrote:
> No, it segfaults.
>
> On Wed, Jul 5, 2017 at 2:26 PM, Andi Vajda  wrote:
>>
>>> On Jul 5, 2017, at 22:16, Joshua Campbell  wrote:
>>>
>>> It's occuring after JCC calls JNI_CreateJavaVM
>>>
>>> cpp.py(529): env = initVM(os.pathsep.join(classpath) or None, 
>>> **initvm_args)
>>> ^ last python trace before death
>>>
>>> Breakpoint 5, initVM (self=0x77e05048, args=0x766deac8,
>>>kwds=0x77e00ec8) at jcc3/sources/jcc.cpp:527
>>> 527 if (JNI_CreateJavaVM(, (void **) _env, _args) < 0)
>>>  last line of jcc.cpp before death
>>>
>>> (gdb) step
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x7fffe43942b4 in ?? ()
>>> (gdb)
>>>
>>>
>>> AFTER fixing debians debugging symbols with ln -s
>>> /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64
>>> /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64
>>>
>>> Breakpoint 1, JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418,
>>>args=0x7fffc450) at ./src/hotspot/src/share/vm/prims/jni.cpp:5161
>>> 5161./src/hotspot/src/share/vm/prims/jni.cpp: No such file or directory.
>>> (gdb) s
>>> JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418, 
>>> args=0x7fffc450)
>>>at ./src/hotspot/src/share/vm/prims/jni.cpp:5163
>>> 5163in ./src/hotspot/src/share/vm/prims/jni.cpp
>>> (gdb)
>>> /build/gdb-A87voC/gdb-7.12/gdb/inline-frame.c:167: internal-error:
>>> void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion
>>> `frame_id_p (*this_id)' failed.
>>> A problem internal to GDB has been detected,
>>> further debugging may prove unreliable.
>>> Quit this debugging session? (y or n) n
>>>
>>> This is a bug, please report it.  For instructions, see:
>>> .
>>>
>>> What in the name of heck
>>
>> Does it run without gdb ?
>>
>> Andi..
>>
>>>
>>> On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell  
>>> wrote:
> But you should get a better stacktrace ?

 I got the exact same stacktrace.

 $ ldd
 venv3/lib/python3.5/site-packages/JCC-3.0-py3.5-linux-x86_64.egg/libjcc3.so
linux-vdso.so.1 (0x7ffcf4eb8000)
libjava.so =>
 /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
 (0x7f412227f000)
libjvm.so =>
 /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
 (0x7f412133d000)
libpython3.5m.so.1.0 =>
 /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 (0x7f4120c3a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 (0x7f41208b8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f41205b4000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
 (0x7f412039b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
 (0x7f412017e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f411fddf000)
libverify.so =>
 /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libverify.so
 (0x7f411fbce000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f411f9ca000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
 (0x7f411f7a)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f411f584000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
 (0x7f411f381000)
/lib64/ld-linux-x86-64.so.2 (0x55857b9dd000)

 I did verify it's compiling with -g

 x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
 -Wstrict-prototypes -g
 -fdebug-prefix-map=/build/python3.5-MLq5fN/python3.5-3.5.3=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
 -D_FORTIFY_SOURCE=2 -fPIC -g -D_java_generics -DJCC_VER="3.0"
 -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include
 -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux -I_jcc3 
 -Ijcc3/sources
 -I/usr/include/python3.5m
 -I/home/joshua/unnaturalcode/venv3/include/python3.5m -c
 _jcc3/java/lang/String.cpp -o
 build/temp.linux-x86_64-3.5/_jcc3/java/lang/String.o -DPYTHON
 -fno-strict-aliasing -Wno-write-strings -O0 -g -DDEBUG

 But it's still producing

 Program received signal SIGSEGV, Segmentation fault.
 0x7fffe47eb2b4 in ?? ()
 (gdb) bt
 #0  0x7fffe47eb2b4 in ?? ()
 #1  0x0246 in ?? ()
 #2  0x7fffe47eb160 in ?? ()
 #3  0x7fffc840 in ?? ()
 #4  0x7fffc7e0 in ?? ()
 #5  0x76006075 in 

Re: Fix versions

[Anshum Gupta]

@Dawid: I remember that discussion, and I think things were fixed for the issue 
back then.

My concern right now is that we will end up in a similar situation again with 
everyone interpreting the fixVersion differently.

@Erick
Here’s my issue with that approach. Say I commit something that would be 
released with 7.0 but obviously, I also commit to master at this point. Going 
with your approach here are the fix versions I’ll end up with on the JIRA - 
master (8.0), 7.1, and 7.0. 

This confuses me, as anything that has a 7.0 fix version shouldn’t have 
anything else from the 7x line. Also, it shouldn’t have anything from a line 
greater than that i.e. master (8.0) as it is obvious to me that there can not 
be any fix that makes it’s way into 7.0 but not 7.1, or 8.0.

Also, from my understanding, a fix version of 7.1 would mean that the first 
time this was released on the 7x line was 7.1 (which wouldn’t be the case here).

Yes, things would work differently for bug fix releases, but I’m talking about 
the major release version here.

Here’s my suggestion:

- For a fix that will be released with a major version, just mention the major 
version
- For a minor version
- master (current version + 1)
- minor version release that would have this fix
- all prior bug fix releases, when this is back-ported to older branches
- Bug fix release
- The only case when a fix is released with such a release, is when 
- The issue was introduced by a minor version release right 
before this release AND
- There was no other minor/major release since this issue was 
introduced.
- In such a case, the fix version should only have the bug fix version, 
and not master, etc.

What would also be useful here is specifying the ‘Affects Version’ but in my 
experience, this gets tough to figure at times for bug fixes, and doesn’t 
generally make sense for new features/enhancements.

If there’s anything else, I’d be happy to just go with whatever everyone wants 
to follow as long as it makes things easier to understand and manage. 


-Anshum



> On Jul 5, 2017, at 2:13 PM, Erick Erickson  wrote:
> 
> I'm just including a fix version for each push I make. I.e.
> 
> If I push to master I'll add "master (8.0)".
> If I push to 7x, at this point I'll add 7.1
> If I push to 7_0 I'll add 7.0
> If I push to 6x I'll add 6.7
> If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
> 
> I think one push == one label is unambiguous. You do have to realize
> that if there may never be, say, a 6.6.1 in my example. But we do
> remove the onus of people having to figure out what a fix version of
> plain "master" or "7x" means.
> 
> FWIW
> Erick
> 
> 
> 
> On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss  wrote:
>> There's been a fairly recent discussion about it on the mailing list
>> (David Smiley and were involved in that discussion, among other
>> people). There are many different takes on how to handle fix-for and
>> branches. I don't think we can find the "best" strategy, although
>> perhaps we can agree on something project-specific. I've expressed my
>> opinion on that previous post, but I'm open to any strategy.
>> 
>> Dawid
>> 
>> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta  wrote:
>>> Hi,
>>> 
>>> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
>>> are being committed right now. I think it makes sense for the fixVersion to
>>> just be 7.0, and nothing else for everything that is going into branch_7_0,
>>> instead of being both 7.0, and master (8.0).
>>> 
>>> Any thoughts?
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
>> 
>> -
>> 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
> 

[jira] [Resolved] (SOLR-10967) Cleanup the default configset

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-10967.
--
   Resolution: Fixed
Fix Version/s: 7.0

Thanks Jason and Jan !

> Cleanup the default configset
> -
>
> Key: SOLR-10967
> URL: https://issues.apache.org/jira/browse/SOLR-10967
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-10967.patch, SOLR-10967.patch, SOLR-10967.patch
>
>
> The schema in the default configset is 1000 lines . We should audit it and 
> see if we can prune it a little bit. 
> Also in this Jira we should fix some of the copy editing . For example, 
> comments like these are outdated 
> {code}
>  This is the Solr schema file. This file should be named "schema.xml" and
>  should be in the conf directory under the solr home
>  (i.e. ./solr/conf/schema.xml by default) 
>  or located where the classloader for the Solr webapp can find it.
> {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-10967) Cleanup the default configset

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10967:


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

SOLR-10967: Cleanup the schema for the default configset


> Cleanup the default configset
> -
>
> Key: SOLR-10967
> URL: https://issues.apache.org/jira/browse/SOLR-10967
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-10967.patch, SOLR-10967.patch, SOLR-10967.patch
>
>
> The schema in the default configset is 1000 lines . We should audit it and 
> see if we can prune it a little bit. 
> Also in this Jira we should fix some of the copy editing . For example, 
> comments like these are outdated 
> {code}
>  This is the Solr schema file. This file should be named "schema.xml" and
>  should be in the conf directory under the solr home
>  (i.e. ./solr/conf/schema.xml by default) 
>  or located where the classloader for the Solr webapp can find it.
> {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-10967) Cleanup the default configset

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10967:


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

SOLR-10967: Cleanup the schema for the default configset


> Cleanup the default configset
> -
>
> Key: SOLR-10967
> URL: https://issues.apache.org/jira/browse/SOLR-10967
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-10967.patch, SOLR-10967.patch, SOLR-10967.patch
>
>
> The schema in the default configset is 1000 lines . We should audit it and 
> see if we can prune it a little bit. 
> Also in this Jira we should fix some of the copy editing . For example, 
> comments like these are outdated 
> {code}
>  This is the Solr schema file. This file should be named "schema.xml" and
>  should be in the conf directory under the solr home
>  (i.e. ./solr/conf/schema.xml by default) 
>  or located where the classloader for the Solr webapp can find it.
> {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-10967) Cleanup the default configset

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10967:


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

SOLR-10967: Cleanup the schema for the default configset


> Cleanup the default configset
> -
>
> Key: SOLR-10967
> URL: https://issues.apache.org/jira/browse/SOLR-10967
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-10967.patch, SOLR-10967.patch, SOLR-10967.patch
>
>
> The schema in the default configset is 1000 lines . We should audit it and 
> see if we can prune it a little bit. 
> Also in this Jira we should fix some of the copy editing . For example, 
> comments like these are outdated 
> {code}
>  This is the Solr schema file. This file should be named "schema.xml" and
>  should be in the conf directory under the solr home
>  (i.e. ./solr/conf/schema.xml by default) 
>  or located where the classloader for the Solr webapp can find it.
> {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

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

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:52106

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:52106
at 
__randomizedtesting.SeedInfo.seed([5593F8D3D14E3F5C:DDC7C7097FB252A4]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1667)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1694)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:297)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] [Created] (SOLR-11017) Add support for unique metric to facet streaming function

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-11017:


 Summary: Add support for unique metric to facet streaming function
 Key: SOLR-11017
 URL: https://issues.apache.org/jira/browse/SOLR-11017
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 6.6
Reporter: Susheel Kumar


Add support for Unique metric to facet function which under the cover utilizes 
JSON Facet API.

The challenge is to come up with a keyword which can be used for UniqueMetric. 
Currently "unique" is used for UniqueStream and can't be utilized.  

Does "uniq" make sense? 

...
...
  StreamFactory factory = new StreamFactory()
  .withCollectionZkHost (...) 
   .withFunctionName("facet", FacetStream.class)
  .withFunctionName("sum", SumMetric.class)
  .withFunctionName("unique", UniqueStream.class)
  .withFunctionName("unique", UniqueMetric.class)
...
...



--
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: Fix versions

[Erick Erickson]

I'm just including a fix version for each push I make. I.e.

If I push to master I'll add "master (8.0)".
If I push to 7x, at this point I'll add 7.1
If I push to 7_0 I'll add 7.0
If I push to 6x I'll add 6.7
If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1

I think one push == one label is unambiguous. You do have to realize
that if there may never be, say, a 6.6.1 in my example. But we do
remove the onus of people having to figure out what a fix version of
plain "master" or "7x" means.

FWIW
Erick



On Wed, Jul 5, 2017 at 1:48 PM, Dawid Weiss  wrote:
> There's been a fairly recent discussion about it on the mailing list
> (David Smiley and were involved in that discussion, among other
> people). There are many different takes on how to handle fix-for and
> branches. I don't think we can find the "best" strategy, although
> perhaps we can agree on something project-specific. I've expressed my
> opinion on that previous post, but I'm open to any strategy.
>
> Dawid
>
> On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta  wrote:
>> Hi,
>>
>> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
>> are being committed right now. I think it makes sense for the fixVersion to
>> just be 7.0, and nothing else for everything that is going into branch_7_0,
>> instead of being both 7.0, and master (8.0).
>>
>> Any thoughts?
>>
>> -Anshum
>>
>>
>>
>
> -
> 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

[jira] [Commented] (SOLR-11015) SocketTimeoutException in ChaosMonkey tests when creating testcollection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11015:


Commit 336218f115474104909e82927044dfd3dcd981e2 in lucene-solr's branch 
refs/heads/branch_7_0 from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=336218f ]

SOLR-11015: Use a higher socket timeout for creating testcollection in 
ChaosMonkeyNothingIsSafe*


> SocketTimeoutException in ChaosMonkey tests when creating testcollection
> 
>
> Key: SOLR-11015
> URL: https://issues.apache.org/jira/browse/SOLR-11015
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-11015.patch
>
>
> I've seen this a couple of times already. Always at the "create collection" 
> operation that all ChaosMonkey tests do at the end of the test to check admin 
> operations continue to work.



--
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-11015) SocketTimeoutException in ChaosMonkey tests when creating testcollection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11015:


Commit 115b70d62d9b2280b585add1c77ff872176ed04d in lucene-solr's branch 
refs/heads/branch_7x from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=115b70d ]

SOLR-11015: Use a higher socket timeout for creating testcollection in 
ChaosMonkeyNothingIsSafe*


> SocketTimeoutException in ChaosMonkey tests when creating testcollection
> 
>
> Key: SOLR-11015
> URL: https://issues.apache.org/jira/browse/SOLR-11015
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-11015.patch
>
>
> I've seen this a couple of times already. Always at the "create collection" 
> operation that all ChaosMonkey tests do at the end of the test to check admin 
> operations continue to work.



--
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-11015) SocketTimeoutException in ChaosMonkey tests when creating testcollection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11015:


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

SOLR-11015: Use a higher socket timeout for creating testcollection in 
ChaosMonkeyNothingIsSafe*


> SocketTimeoutException in ChaosMonkey tests when creating testcollection
> 
>
> Key: SOLR-11015
> URL: https://issues.apache.org/jira/browse/SOLR-11015
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-11015.patch
>
>
> I've seen this a couple of times already. Always at the "create collection" 
> operation that all ChaosMonkey tests do at the end of the test to check admin 
> operations continue to work.



--
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: [JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 6 - Unstable!

[Michael McCandless]

I pushed a fix for these failures.

Mike McCandless

http://blog.mikemccandless.com

On Wed, Jul 5, 2017 at 4:30 PM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/6/
> Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
>
> 1 tests failed.
> FAILED:  org.apache.lucene.index.TestMixedDocValuesUpdates.
> testManyReopensAndFields
>
> Error Message:
> invalid numeric value for doc=0, field=f0, 
> reader=_g(7.1.0):c51:fieldInfosGen=1:dvGen=1
> expected:<3> but was:<2>
>
> Stack Trace:
> java.lang.AssertionError: invalid numeric value for doc=0, field=f0,
> reader=_g(7.1.0):c51:fieldInfosGen=1:dvGen=1 expected:<3> but was:<2>
> at __randomizedtesting.SeedInfo.seed([482E0B60E01B5A8E:
> 7ED2694F61EE3992]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.apache.lucene.index.TestMixedDocValuesUpdates.
> testManyReopensAndFields(TestMixedDocValuesUpdates.java:138)
> 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:1713)
> at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(
> RandomizedRunner.java:907)
> at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(
> RandomizedRunner.java:943)
> at com.carrotsearch.randomizedtesting.
> RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
> 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:916)
> at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(
> RandomizedRunner.java:802)
> at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(
> RandomizedRunner.java:852)
> at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(
> RandomizedRunner.java:863)
> 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 

Re: Fix versions

[Dawid Weiss]

There's been a fairly recent discussion about it on the mailing list
(David Smiley and were involved in that discussion, among other
people). There are many different takes on how to handle fix-for and
branches. I don't think we can find the "best" strategy, although
perhaps we can agree on something project-specific. I've expressed my
opinion on that previous post, but I'm open to any strategy.

Dawid

On Wed, Jul 5, 2017 at 10:42 PM, Anshum Gupta  wrote:
> Hi,
>
> I was a bit confused in terms of setting the ‘fix version’ for JIRAs that
> are being committed right now. I think it makes sense for the fixVersion to
> just be 7.0, and nothing else for everything that is going into branch_7_0,
> instead of being both 7.0, and master (8.0).
>
> Any thoughts?
>
> -Anshum
>
>
>

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

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 1945 - Unstable

[Tomas Fernandez Lobbe]

Related to SOLR-11015. I missed the case of the ChaosMonkeyNothingIsSafe*, that 
creates a different client with an explicit timeout for creating this 
collection. 

> On Jul 5, 2017, at 1:22 PM, Apache Jenkins Server  
> wrote:
> 
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1945/
> 
> 3 tests failed.
> FAILED:  
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test
> 
> Error Message:
> Timeout occured while waiting response from server at: 
> http://127.0.0.1:35634/d/d
> 
> Stack Trace:
> org.apache.solr.client.solrj.SolrServerException: Timeout occured while 
> waiting response from server at: http://127.0.0.1:35634/d/d
>   at 
> __randomizedtesting.SeedInfo.seed([FFF3B976A4923FDD:77A786AC0A6E5225]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
>   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.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1667)
>   at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1694)
>   at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:297)
>   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:1713)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
>   at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>   at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>   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:916)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   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 
> 

[jira] [Resolved] (SOLR-11004) Consolidate SolrClient Builder code in abstract parent class

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-11004.
-
Resolution: Fixed

> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: 7.0
>
> Attachments: SOLR-11004.patch, SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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-11004) Consolidate SolrClient Builder code in abstract parent class

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11004:

Fix Version/s: (was: master (8.0))

> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: 7.0
>
> Attachments: SOLR-11004.patch, SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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

Fix versions

[Anshum Gupta]

Hi,

I was a bit confused in terms of setting the ‘fix version’ for JIRAs that are 
being committed right now. I think it makes sense for the fixVersion to just be 
7.0, and nothing else for everything that is going into branch_7_0, instead of 
being both 7.0, and master (8.0). 

Any thoughts?

-Anshum

[jira] [Commented] (SOLR-11004) Consolidate SolrClient Builder code in abstract parent class

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11004:


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

SOLR-11004: Consolidate SolrClient builder code into an abstract base class to 
reduce duplication.


> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11004.patch, SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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: JCC Segfault on Debian 9 (stretch)

[Joshua Campbell]

No, it segfaults.

On Wed, Jul 5, 2017 at 2:26 PM, Andi Vajda  wrote:
>
>> On Jul 5, 2017, at 22:16, Joshua Campbell  wrote:
>>
>> It's occuring after JCC calls JNI_CreateJavaVM
>>
>> cpp.py(529): env = initVM(os.pathsep.join(classpath) or None, 
>> **initvm_args)
>> ^ last python trace before death
>>
>> Breakpoint 5, initVM (self=0x77e05048, args=0x766deac8,
>>kwds=0x77e00ec8) at jcc3/sources/jcc.cpp:527
>> 527 if (JNI_CreateJavaVM(, (void **) _env, _args) < 0)
>>  last line of jcc.cpp before death
>>
>> (gdb) step
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x7fffe43942b4 in ?? ()
>> (gdb)
>>
>>
>> AFTER fixing debians debugging symbols with ln -s
>> /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64
>> /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64
>>
>> Breakpoint 1, JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418,
>>args=0x7fffc450) at ./src/hotspot/src/share/vm/prims/jni.cpp:5161
>> 5161./src/hotspot/src/share/vm/prims/jni.cpp: No such file or directory.
>> (gdb) s
>> JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418, 
>> args=0x7fffc450)
>>at ./src/hotspot/src/share/vm/prims/jni.cpp:5163
>> 5163in ./src/hotspot/src/share/vm/prims/jni.cpp
>> (gdb)
>> /build/gdb-A87voC/gdb-7.12/gdb/inline-frame.c:167: internal-error:
>> void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion
>> `frame_id_p (*this_id)' failed.
>> A problem internal to GDB has been detected,
>> further debugging may prove unreliable.
>> Quit this debugging session? (y or n) n
>>
>> This is a bug, please report it.  For instructions, see:
>> .
>>
>> What in the name of heck
>
> Does it run without gdb ?
>
> Andi..
>
>>
>> On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell  wrote:
 But you should get a better stacktrace ?
>>>
>>> I got the exact same stacktrace.
>>>
>>> $ ldd
>>> venv3/lib/python3.5/site-packages/JCC-3.0-py3.5-linux-x86_64.egg/libjcc3.so
>>>linux-vdso.so.1 (0x7ffcf4eb8000)
>>>libjava.so =>
>>> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
>>> (0x7f412227f000)
>>>libjvm.so =>
>>> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
>>> (0x7f412133d000)
>>>libpython3.5m.so.1.0 =>
>>> /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 (0x7f4120c3a000)
>>>libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>> (0x7f41208b8000)
>>>libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f41205b4000)
>>>libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>>> (0x7f412039b000)
>>>libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>>> (0x7f412017e000)
>>>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f411fddf000)
>>>libverify.so =>
>>> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libverify.so
>>> (0x7f411fbce000)
>>>libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f411f9ca000)
>>>libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
>>> (0x7f411f7a)
>>>libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f411f584000)
>>>libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
>>> (0x7f411f381000)
>>>/lib64/ld-linux-x86-64.so.2 (0x55857b9dd000)
>>>
>>> I did verify it's compiling with -g
>>>
>>> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
>>> -Wstrict-prototypes -g
>>> -fdebug-prefix-map=/build/python3.5-MLq5fN/python3.5-3.5.3=.
>>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>>> -D_FORTIFY_SOURCE=2 -fPIC -g -D_java_generics -DJCC_VER="3.0"
>>> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include
>>> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux -I_jcc3 -Ijcc3/sources
>>> -I/usr/include/python3.5m
>>> -I/home/joshua/unnaturalcode/venv3/include/python3.5m -c
>>> _jcc3/java/lang/String.cpp -o
>>> build/temp.linux-x86_64-3.5/_jcc3/java/lang/String.o -DPYTHON
>>> -fno-strict-aliasing -Wno-write-strings -O0 -g -DDEBUG
>>>
>>> But it's still producing
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x7fffe47eb2b4 in ?? ()
>>> (gdb) bt
>>> #0  0x7fffe47eb2b4 in ?? ()
>>> #1  0x0246 in ?? ()
>>> #2  0x7fffe47eb160 in ?? ()
>>> #3  0x7fffc840 in ?? ()
>>> #4  0x7fffc7e0 in ?? ()
>>> #5  0x76006075 in VM_Version::get_processor_features() ()
>>>   from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>>
>>>
>>>
>>>
 On Wed, Jul 5, 2017 at 11:38 AM, Andi Vajda  wrote:


 On Jul 5, 2017, at 18:56, Joshua Campbell  wrote:

>> What version if java is this jcc built with ?
>> To build jcc for debugging with gcc add --debug to the build command.

[jira] [Comment Edited] (SOLR-10996) Implement TriggerListener API

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  edited comment on SOLR-10996 at 7/5/17 8:33 PM:
--

Patch for review:
* some refactoring to clarify what are the user-visible listeners as opposed to 
internal event processors,
* improved {{AutoScalingConfig}} and instantiation of listeners in 
{{ScheduledTriggers.TriggerListeners}},
* unit tests.

This is a sizeable patch, it's probably better to review the changes using 
branch {{jira/solr-10996}}.
(Edit: well, not a big patch, but confusing due to renames...)


was (Author: ab):
Patch for review:
* some refactoring to clarify what are the user-visible listeners as opposed to 
internal event processors,
* improved {{AutoScalingConfig}} and instantiation of listeners in 
{{ScheduledTriggers.TriggerListeners}},
* unit tests.

This is a sizeable patch, it's probably better to review the changes using 
branch {{jira/solr-10996}}.

> Implement TriggerListener API
> -
>
> Key: SOLR-10996
> URL: https://issues.apache.org/jira/browse/SOLR-10996
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Attachments: SOLR-10996.patch
>
>
> SOLR-10340 added API for configuring trigger listeners. This issue is about 
> adding hooks in the framework for calling the listeners and providing a 
> couple implementations (HTTP callback, logging).



--
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-10996) Implement TriggerListener API

[Andrzej Bialecki (JIRA)]

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

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

Patch for review:
* some refactoring to clarify what are the user-visible listeners as opposed to 
internal event processors,
* improved {{AutoScalingConfig}} and instantiation of listeners in 
{{ScheduledTriggers.TriggerListeners}},
* unit tests.

This is a sizeable patch, it's probably better to review the changes using 
branch {{jira/solr-10996}}.

> Implement TriggerListener API
> -
>
> Key: SOLR-10996
> URL: https://issues.apache.org/jira/browse/SOLR-10996
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Attachments: SOLR-10996.patch
>
>
> SOLR-10340 added API for configuring trigger listeners. This issue is about 
> adding hooks in the framework for calling the listeners and providing a 
> couple implementations (HTTP callback, logging).



--
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 # 6 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.lucene.index.TestMixedDocValuesUpdates.testManyReopensAndFields

Error Message:
invalid numeric value for doc=0, field=f0, 
reader=_g(7.1.0):c51:fieldInfosGen=1:dvGen=1 expected:<3> but was:<2>

Stack Trace:
java.lang.AssertionError: invalid numeric value for doc=0, field=f0, 
reader=_g(7.1.0):c51:fieldInfosGen=1:dvGen=1 expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([482E0B60E01B5A8E:7ED2694F61EE3992]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.lucene.index.TestMixedDocValuesUpdates.testManyReopensAndFields(TestMixedDocValuesUpdates.java:138)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 372 lines...]
   [junit4] Suite: org.apache.lucene.index.TestMixedDocValuesUpdates
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestMixedDocValuesUpdates -Dtests.method=testManyReopensAndFields 
-Dtests.seed=482E0B60E01B5A8E -Dtests.slow=true -Dtests.locale=ru-RU 
-Dtests.timezone=Asia/Ust-Nera 

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

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:35634/d/d

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:35634/d/d
at 
__randomizedtesting.SeedInfo.seed([FFF3B976A4923FDD:77A786AC0A6E5225]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1667)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1694)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:297)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Policeman Jenkins Server]

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

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

Error Message:
9 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest: 1) Thread[id=2069, 
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[39890E0FFA780607]-SendThread(127.0.0.1:41433),
 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)
2) Thread[id=2070, 
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[39890E0FFA780607]-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)
3) Thread[id=2290, name=zkCallback-396-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:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:748)4) Thread[id=2068, 
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=2289, 
name=zkCallback-396-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:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:748)6) Thread[id=2309, 
name=zkCallback-396-thread-4, 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:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:748)7) Thread[id=2385, 
name=zkCallback-396-thread-6, 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:1066)   
  at 

Re: JCC Segfault on Debian 9 (stretch)

[Joshua Campbell]

It's occuring after JCC calls JNI_CreateJavaVM

cpp.py(529): env = initVM(os.pathsep.join(classpath) or None, **initvm_args)
^ last python trace before death

Breakpoint 5, initVM (self=0x77e05048, args=0x766deac8,
kwds=0x77e00ec8) at jcc3/sources/jcc.cpp:527
527 if (JNI_CreateJavaVM(, (void **) _env, _args) < 0)
 last line of jcc.cpp before death

(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x7fffe43942b4 in ?? ()
(gdb)


AFTER fixing debians debugging symbols with ln -s
/usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64
/usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64

Breakpoint 1, JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418,
args=0x7fffc450) at ./src/hotspot/src/share/vm/prims/jni.cpp:5161
5161./src/hotspot/src/share/vm/prims/jni.cpp: No such file or directory.
(gdb) s
JNI_CreateJavaVM (vm=0x7fffc420, penv=0x7fffc418, args=0x7fffc450)
at ./src/hotspot/src/share/vm/prims/jni.cpp:5163
5163in ./src/hotspot/src/share/vm/prims/jni.cpp
(gdb)
/build/gdb-A87voC/gdb-7.12/gdb/inline-frame.c:167: internal-error:
void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion
`frame_id_p (*this_id)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
.

What in the name of heck

On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell  wrote:
>> But you should get a better stacktrace ?
>
> I got the exact same stacktrace.
>
> $ ldd
> venv3/lib/python3.5/site-packages/JCC-3.0-py3.5-linux-x86_64.egg/libjcc3.so
> linux-vdso.so.1 (0x7ffcf4eb8000)
> libjava.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
> (0x7f412227f000)
> libjvm.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
> (0x7f412133d000)
> libpython3.5m.so.1.0 =>
> /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 (0x7f4120c3a000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f41208b8000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f41205b4000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f412039b000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f412017e000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f411fddf000)
> libverify.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libverify.so
> (0x7f411fbce000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f411f9ca000)
> libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
> (0x7f411f7a)
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f411f584000)
> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
> (0x7f411f381000)
> /lib64/ld-linux-x86-64.so.2 (0x55857b9dd000)
>
> I did verify it's compiling with -g
>
> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -g
> -fdebug-prefix-map=/build/python3.5-MLq5fN/python3.5-3.5.3=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -fPIC -g -D_java_generics -DJCC_VER="3.0"
> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include
> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux -I_jcc3 -Ijcc3/sources
> -I/usr/include/python3.5m
> -I/home/joshua/unnaturalcode/venv3/include/python3.5m -c
> _jcc3/java/lang/String.cpp -o
> build/temp.linux-x86_64-3.5/_jcc3/java/lang/String.o -DPYTHON
> -fno-strict-aliasing -Wno-write-strings -O0 -g -DDEBUG
>
> But it's still producing
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffe47eb2b4 in ?? ()
> (gdb) bt
> #0  0x7fffe47eb2b4 in ?? ()
> #1  0x0246 in ?? ()
> #2  0x7fffe47eb160 in ?? ()
> #3  0x7fffc840 in ?? ()
> #4  0x7fffc7e0 in ?? ()
> #5  0x76006075 in VM_Version::get_processor_features() ()
>from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
>
>
>
> On Wed, Jul 5, 2017 at 11:38 AM, Andi Vajda  wrote:
>>
>>
>> On Jul 5, 2017, at 18:56, Joshua Campbell  wrote:
>>
>> >> What version if java is this jcc built with ?
>> >> To build jcc for debugging with gcc add --debug to the build command.
>> >> You
>> > should then have symbols visible to gdb.
>> >
>> > You mean with setup.py build --debug ? I tried that on trunk and got the
>> > same result.
>>
>> But you should get a better stacktrace ?
>>
>> >> Is the version of java used here the same as during jcc build time ?
>> >
>> > Yes I made sure of that and uninstalled all but openjdk and rebuilt.
>>
>> Did you verify this via running 'ldd' on the shared libraries involved ?
>>
>> That being said, 

[jira] [Updated] (SOLR-10668) NPE on sort=childfield(field) desc

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-10668:

Summary: NPE on sort=childfield(field) desc  (was: add a test for 
sort=childfield(name,$another_bjq) desc)

> NPE on sort=childfield(field) desc
> --
>
> Key: SOLR-10668
> URL: https://issues.apache.org/jira/browse/SOLR-10668
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Attachments: SOLR-10668.patch
>
>
> Not a big deal, just a test, I should have one somewhere around.



--
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-10668) add a test for sort=childfield(name,$another_bjq) desc

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-10668 at 7/5/17 7:55 PM:
-

also, it seems like absent values cause NPE


was (Author: mkhludnev):
also, it seems like absent values leads to NPE

> add a test for sort=childfield(name,$another_bjq) desc
> --
>
> Key: SOLR-10668
> URL: https://issues.apache.org/jira/browse/SOLR-10668
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10668.patch
>
>
> Not a big deal, just a test, I should have one somewhere around.



--
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-10668) add a test for sort=childfield(name,$another_bjq) desc

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-10668:

Issue Type: Bug  (was: Test)

> add a test for sort=childfield(name,$another_bjq) desc
> --
>
> Key: SOLR-10668
> URL: https://issues.apache.org/jira/browse/SOLR-10668
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Attachments: SOLR-10668.patch
>
>
> Not a big deal, just a test, I should have one somewhere around.



--
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] [Assigned] (SOLR-10668) add a test for sort=childfield(name,$another_bjq) desc

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev reassigned SOLR-10668:
---

Assignee: Mikhail Khludnev

> add a test for sort=childfield(name,$another_bjq) desc
> --
>
> Key: SOLR-10668
> URL: https://issues.apache.org/jira/browse/SOLR-10668
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Attachments: SOLR-10668.patch
>
>
> Not a big deal, just a test, I should have one somewhere around.



--
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-10668) add a test for sort=childfield(name,$another_bjq) desc

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-10668:

Attachment: SOLR-10668.patch

[^SOLR-10668.patch] is mostly NPE fix

> add a test for sort=childfield(name,$another_bjq) desc
> --
>
> Key: SOLR-10668
> URL: https://issues.apache.org/jira/browse/SOLR-10668
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10668.patch
>
>
> Not a big deal, just a test, I should have one somewhere around.



--
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-10668) add a test for sort=childfield(name,$another_bjq) desc

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-10668 at 7/5/17 7:50 PM:
-

also, it's worth to cover -inlining bjq- _it's not possible since it has space_


was (Author: mkhludnev):
also, it's worth to cover inlining bjq

> add a test for sort=childfield(name,$another_bjq) desc
> --
>
> Key: SOLR-10668
> URL: https://issues.apache.org/jira/browse/SOLR-10668
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>
> Not a big deal, just a test, I should have one somewhere around.



--
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-10123) Analytics Component 2.0

[ASF GitHub Bot (JIRA)]

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

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

Github user dennisgove commented on the issue:

https://github.com/apache/lucene-solr/pull/215
  
This all looks good to me so far

`%> ant precommit` passes
`%> ant test` passes

Houston is working on a new batch of tests that will specifically test the 
new analytics expression language. I'm going to wait until those are added (and 
checked) before merging this PR.

@hossman, do you have any other concerns about this and/or possible 
ramifications of this change?


> Analytics Component 2.0
> ---
>
> Key: SOLR-10123
> URL: https://issues.apache.org/jira/browse/SOLR-10123
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Houston Putman
>  Labels: features
> Attachments: SOLR-10123.patch, SOLR-10123.patch, SOLR-10123.patch
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * New JSON request language, and response format that fits JSON better.
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
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_131) - Build # 20067 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20067/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseG1GC

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

Error Message:
9 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest: 1) Thread[id=2457, 
name=zkCallback-348-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:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:748)2) Thread[id=2248, 
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)3) Thread[id=2412, 
name=zkCallback-348-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:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:748)4) Thread[id=2250, 
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[718073425C455411]-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)
5) Thread[id=2431, name=zkCallback-348-thread-4, 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:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:748)6) Thread[id=2419, 
name=zkCallback-348-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:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:748)7) Thread[id=2471, 
name=zkCallback-348-thread-6, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 

[GitHub] lucene-solr issue #215: SOLR-10123: Fix to better support numeric PointField...

[dennisgove]

Github user dennisgove commented on the issue:

https://github.com/apache/lucene-solr/pull/215
  
This all looks good to me so far

`%> ant precommit` passes
`%> ant test` passes

Houston is working on a new batch of tests that will specifically test the 
new analytics expression language. I'm going to wait until those are added (and 
checked) before merging this PR.

@hossman, do you have any other concerns about this and/or possible 
ramifications of this change?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:49823/ne

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:49823/ne
at 
__randomizedtesting.SeedInfo.seed([BBF97D21FDD7ACAA:33AD42FB532BC152]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1667)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1694)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:297)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] [Commented] (SOLR-10583) Add 'join' as a new type of domain change in JSON Facets

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10583:
---

{{TestCloudJSONFacetJoinDomain}}, introduced on this issue, has a reproducible 
failure: SOLR-11016.

> Add 'join' as a new type of domain change in JSON Facets
> 
>
> Key: SOLR-10583
> URL: https://issues.apache.org/jira/browse/SOLR-10583
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.6, 7.0
>
> Attachments: SOLR-10583.patch, SOLR-10583.patch, SOLR-10583.patch
>
>
> Add support for a new (query) {{join}} option when specifying a {{domain}} 
> for a JSON Facet.
> Suggested syntax...
> {code}
> ...
> domain : { join : { from : field_foo,
> to : field_bar
> }
>}
> {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-11016) TestCloudJSONFacetJoinDomain.testBespoke() failures

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11016:
--
Description: 
Policeman Jenkins found a reproducing branch_6x seed 
[https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/980/]:

{noformat}
Checking out Revision 9947a811e83cc0f848f9ddaa37a4137f19efff1a 
(refs/remotes/origin/branch_6x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestCloudJSONFacetJoinDomain -Dtests.method=testBespoke 
-Dtests.seed=CF428F9440CE16E -Dtests.slow=true -Dtests.locale=cs 
-Dtests.timezone=America/Aruba -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 1.72s J1 | TestCloudJSONFacetJoinDomain.testBespoke <<<
   [junit4]> Throwable #1: java.lang.AssertionError: 
{main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
 ===> 
{responseHeader={zkConnected=true,status=0,QTime=5},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
 --> top key missing from: {count=0}
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CF428F9440CE16E:72FACC08C8C2699]:0)
   [junit4]>at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
   [junit4]>at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
   [junit4]> Caused by: java.lang.AssertionError: top key missing from: 
{count=0}
   [junit4]>at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:351)
   [junit4]>at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:331)
[...]
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=RandomSimilarity(queryNorm=true,coord=crazy): {}, locale=cs, 
timezone=America/Aruba
   [junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_131 
(64-bit)/cpus=3,threads=1,free=58802776,total=266338304
{noformat}

Another reproducing branch_6x seed, from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/849/] (job history has 
been removed since it's too old - notification email arrived on May 24th):

{noformat}
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke

Error Message:
{main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
 ===> 
{responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
 --> top key missing from: {count=0}

Stack Trace:
java.lang.AssertionError: 
{main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
 ===> 
{responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
 --> top key missing from: {count=0}
at 
__randomizedtesting.SeedInfo.seed([D2F19637CE167869:D92A120E0696BF9E]:0)
at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
{noformat}

Note that both of the above seeds reproduce for me on Linux with Java8.

  was:
Policeman Jenkins found a reproducing branch_6x seed 
[https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/980/]:

{noformat}
Checking out Revision 9947a811e83cc0f848f9ddaa37a4137f19efff1a 
(refs/remotes/origin/branch_6x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestCloudJSONFacetJoinDomain -Dtests.method=testBespoke 
-Dtests.seed=CF428F9440CE16E -Dtests.slow=true -Dtests.locale=cs 
-Dtests.timezone=America/Aruba -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 1.72s J1 | TestCloudJSONFacetJoinDomain.testBespoke <<<
   [junit4]> Throwable #1: java.lang.AssertionError: 
{main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
 ===> 
{responseHeader={zkConnected=true,status=0,QTime=5},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
 --> top key missing from: {count=0}
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CF428F9440CE16E:72FACC08C8C2699]:0)
   [junit4]>at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
   [junit4]>  

[jira] [Moved] (SOLR-11016) TestCloudJSONFacetJoinDomain.testBespoke() failures

[Steve Rowe (JIRA)]

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

Steve Rowe moved LUCENE-7900 to SOLR-11016:
---

 Security: Public
Lucene Fields:   (was: New)
  Key: SOLR-11016  (was: LUCENE-7900)
  Project: Solr  (was: Lucene - Core)

> TestCloudJSONFacetJoinDomain.testBespoke() failures
> ---
>
> Key: SOLR-11016
> URL: https://issues.apache.org/jira/browse/SOLR-11016
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> Policeman Jenkins found a reproducing branch_6x seed 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/980/]:
> {noformat}
> Checking out Revision 9947a811e83cc0f848f9ddaa37a4137f19efff1a 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestCloudJSONFacetJoinDomain -Dtests.method=testBespoke 
> -Dtests.seed=CF428F9440CE16E -Dtests.slow=true -Dtests.locale=cs 
> -Dtests.timezone=America/Aruba -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.72s J1 | TestCloudJSONFacetJoinDomain.testBespoke <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> {main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
>  ===> 
> {responseHeader={zkConnected=true,status=0,QTime=5},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
>  --> top key missing from: {count=0}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([CF428F9440CE16E:72FACC08C8C2699]:0)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
>[junit4]> Caused by: java.lang.AssertionError: top key missing from: 
> {count=0}
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:351)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:331)
> [...]
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=RandomSimilarity(queryNorm=true,coord=crazy): {}, locale=cs, 
> timezone=America/Aruba
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_131 
> (64-bit)/cpus=3,threads=1,free=58802776,total=266338304
> {noformat}
> Another reproducing branch_6x seed, from 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/849/] (job history 
> has been removed since it's too old - notification email arrived on May 24th):
> {noformat}
> Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC
> 1 tests failed.
> FAILED:  org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke
> Error Message:
> {main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
>  ===> 
> {responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
>  --> top key missing from: {count=0}
> Stack Trace:
> java.lang.AssertionError: 
> {main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
>  ===> 
> {responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
>  --> top key missing from: {count=0}
>   at 
> __randomizedtesting.SeedInfo.seed([D2F19637CE167869:D92A120E0696BF9E]:0)
>   at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
>   at 
> org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
> {noformat}



--
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] (LUCENE-7900) TestCloudJSONFacetJoinDomain.testBespoke() failures

[Steve Rowe (JIRA)]

Steve Rowe created LUCENE-7900:
--

 Summary: TestCloudJSONFacetJoinDomain.testBespoke() failures
 Key: LUCENE-7900
 URL: https://issues.apache.org/jira/browse/LUCENE-7900
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe


Policeman Jenkins found a reproducing branch_6x seed 
[https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/980/]:

{noformat}
Checking out Revision 9947a811e83cc0f848f9ddaa37a4137f19efff1a 
(refs/remotes/origin/branch_6x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestCloudJSONFacetJoinDomain -Dtests.method=testBespoke 
-Dtests.seed=CF428F9440CE16E -Dtests.slow=true -Dtests.locale=cs 
-Dtests.timezone=America/Aruba -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 1.72s J1 | TestCloudJSONFacetJoinDomain.testBespoke <<<
   [junit4]> Throwable #1: java.lang.AssertionError: 
{main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
 ===> 
{responseHeader={zkConnected=true,status=0,QTime=5},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
 --> top key missing from: {count=0}
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CF428F9440CE16E:72FACC08C8C2699]:0)
   [junit4]>at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
   [junit4]>at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
   [junit4]> Caused by: java.lang.AssertionError: top key missing from: 
{count=0}
   [junit4]>at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:351)
   [junit4]>at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:331)
[...]
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=RandomSimilarity(queryNorm=true,coord=crazy): {}, locale=cs, 
timezone=America/Aruba
   [junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_131 
(64-bit)/cpus=3,threads=1,free=58802776,total=266338304
{noformat}

Another reproducing branch_6x seed, from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/849/] (job history has 
been removed since it's too old - notification email arrived on May 24th):

{noformat}
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke

Error Message:
{main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
 ===> 
{responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
 --> top key missing from: {count=0}

Stack Trace:
java.lang.AssertionError: 
{main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)=0)}
 ===> 
{responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
 --> top key missing from: {count=0}
at 
__randomizedtesting.SeedInfo.seed([D2F19637CE167869:D92A120E0696BF9E]:0)
at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
{noformat}



--
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-11015) SocketTimeoutException in ChaosMonkey tests when creating testcollection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11015:


Commit 7e3d48222f3aa0176f2b451b926f22b21a808b87 in lucene-solr's branch 
refs/heads/branch_7_0 from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7e3d482 ]

SOLR-11015: Increase socket timeout time for client used for admin operations 
in ChaosMonkey tests


> SocketTimeoutException in ChaosMonkey tests when creating testcollection
> 
>
> Key: SOLR-11015
> URL: https://issues.apache.org/jira/browse/SOLR-11015
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-11015.patch
>
>
> I've seen this a couple of times already. Always at the "create collection" 
> operation that all ChaosMonkey tests do at the end of the test to check admin 
> operations continue to work.



--
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-11004) Consolidate SolrClient Builder code in abstract parent class

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11004:


Commit 454950aae6bb155ded2085d13fea062654b5af28 in lucene-solr's branch 
refs/heads/branch_7x from [~anshumg]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=454950a ]

SOLR-11004: Consolidate SolrClient builder code into an abstract base class to 
reduce duplication.


> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11004.patch, SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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-11015) SocketTimeoutException in ChaosMonkey tests when creating testcollection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11015:


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

SOLR-11015: Increase socket timeout time for client used for admin operations 
in ChaosMonkey tests


> SocketTimeoutException in ChaosMonkey tests when creating testcollection
> 
>
> Key: SOLR-11015
> URL: https://issues.apache.org/jira/browse/SOLR-11015
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-11015.patch
>
>
> I've seen this a couple of times already. Always at the "create collection" 
> operation that all ChaosMonkey tests do at the end of the test to check admin 
> operations continue to work.



--
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-11015) SocketTimeoutException in ChaosMonkey tests when creating testcollection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11015:


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

SOLR-11015: Increase socket timeout time for client used for admin operations 
in ChaosMonkey tests


> SocketTimeoutException in ChaosMonkey tests when creating testcollection
> 
>
> Key: SOLR-11015
> URL: https://issues.apache.org/jira/browse/SOLR-11015
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-11015.patch
>
>
> I've seen this a couple of times already. Always at the "create collection" 
> operation that all ChaosMonkey tests do at the end of the test to check admin 
> operations continue to work.



--
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-11004) Consolidate SolrClient Builder code in abstract parent class

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11004:

Fix Version/s: 7.0

> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11004.patch, SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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-11004) Consolidate SolrClient Builder code in abstract parent class

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11004:

Affects Version/s: (was: master (8.0))

> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11004.patch, SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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] [Assigned] (SOLR-11004) Consolidate SolrClient Builder code in abstract parent class

[Anshum Gupta (JIRA)]

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

Anshum Gupta reassigned SOLR-11004:
---

Assignee: Anshum Gupta

> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-11004.patch, SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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-11004) Consolidate SolrClient Builder code in abstract parent class

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11004:


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

SOLR-11004: Consolidate SolrClient builder code into an abstract base class to 
reduce duplication.


> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-11004.patch, SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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-11004) Consolidate SolrClient Builder code in abstract parent class

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11004:

Attachment: SOLR-11004.patch

Updated patch

> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-11004.patch, SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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-11015) SocketTimeoutException in ChaosMonkey tests when creating testcollection

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-11015:
-
Attachment: SOLR-11015.patch

Patch to increase the socket timeout in the {{createNewSolrClient(String, 
String)}} method of the test, the same as we do for other clients

> SocketTimeoutException in ChaosMonkey tests when creating testcollection
> 
>
> Key: SOLR-11015
> URL: https://issues.apache.org/jira/browse/SOLR-11015
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-11015.patch
>
>
> I've seen this a couple of times already. Always at the "create collection" 
> operation that all ChaosMonkey tests do at the end of the test to check admin 
> operations continue to work.



--
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-11004) Consolidate SolrClient Builder code in abstract parent class

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-11004:
-

Thanks Jason, I've changed this a bit to remove the {{suppressed}} warnings, by 
adding an abstract {{getThis()}} method and implementing it in all classes. 
Running the tests now before I commit.

> Consolidate SolrClient Builder code in abstract parent class
> 
>
> Key: SOLR-11004
> URL: https://issues.apache.org/jira/browse/SOLR-11004
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-11004.patch
>
>
> As [~anshumg] pointed out in SOLR-10456, the Builder code for each SolrClient 
> has a lot of duplication in it.
> For example, each SolrClient allows configuration of the connection timeout: 
> all 4 builders have a field to store this value, all 4 builders have a 
> {{withConnectionTimeout}} method to set this value, and all 4 builders have 
> very similar Javadocs documenting what this value can be used for.
> The same can be said for 5 or 6 other properties common to most/all 
> SolrClient's.
> This duplication could be removed by creating an abstract SolrClientBuilder 
> class, which each of the specific Builders extend.



--
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-11015) SocketTimeoutException in ChaosMonkey tests when creating testcollection

[JIRA]

Tomás Fernández Löbbe created SOLR-11015:


 Summary: SocketTimeoutException in ChaosMonkey tests when creating 
testcollection
 Key: SOLR-11015
 URL: https://issues.apache.org/jira/browse/SOLR-11015
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Tomás Fernández Löbbe
Assignee: Tomás Fernández Löbbe
Priority: Minor


I've seen this a couple of times already. Always at the "create collection" 
operation that all ChaosMonkey tests do at the end of the test to check admin 
operations continue to work.



--
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-7899) Rename FieldValueQuery to DocValuesFieldExistsQuery

[ASF subversion and git services (JIRA)]

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

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

Commit f288b440b76f6b2ab23cc134054e2b1d374d182a in lucene-solr's branch 
refs/heads/branch_7_0 from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f288b44 ]

LUCENE-7899: add text after header in MIGRATE.txt


> Rename FieldValueQuery to DocValuesFieldExistsQuery
> ---
>
> Key: LUCENE-7899
> URL: https://issues.apache.org/jira/browse/LUCENE-7899
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 7.0, master (8.0)
>
> Attachments: LUCENE-7899.patch
>
>
> I don't think we have a query today to efficiently test whether a doc values 
> field exists (has any value) for each document in the index?
> Now that we use iterators to access doc values, this should be an efficient 
> query: we can return the DISI we get for the doc values.
> ElasticSearch indexes its own field to record which field names occur in a 
> document, so it's able to do "exists" for any field (not just doc values 
> fields), but I think doc values fields we can just get "for free".
> I haven't started on this ... just wanted to open the issue first for 
> discussion.



--
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-7899) Rename FieldValueQuery to DocValuesFieldExistsQuery

[ASF subversion and git services (JIRA)]

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

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

Commit b52974f3386746b1b529243afc7fa321d9b204bb in lucene-solr's branch 
refs/heads/branch_7x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b52974f ]

LUCENE-7899: add text after header in MIGRATE.txt


> Rename FieldValueQuery to DocValuesFieldExistsQuery
> ---
>
> Key: LUCENE-7899
> URL: https://issues.apache.org/jira/browse/LUCENE-7899
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 7.0, master (8.0)
>
> Attachments: LUCENE-7899.patch
>
>
> I don't think we have a query today to efficiently test whether a doc values 
> field exists (has any value) for each document in the index?
> Now that we use iterators to access doc values, this should be an efficient 
> query: we can return the DISI we get for the doc values.
> ElasticSearch indexes its own field to record which field names occur in a 
> document, so it's able to do "exists" for any field (not just doc values 
> fields), but I think doc values fields we can just get "for free".
> I haven't started on this ... just wanted to open the issue first for 
> discussion.



--
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: lucene-solr:branch_7x: LUCENE-7899: add entry in MIGRATE.txt

[Michael McCandless]

Oh, I'll add a line of text there.  Thanks Uwe.

+1 to rename our Markdown files to .md!

Mike McCandless

http://blog.mikemccandless.com

On Wed, Jul 5, 2017 at 11:36 AM, Uwe Schindler  wrote:

> Hi,
>
> we now have an entry heading at the end of the migrate.txt file (which is
> formatted in Markdown). We should maybe add some line of text.
>
> I think after changing the README.txt filename to README.md, we should
> maybe do the same with the other Markdown formatted files (see the ant
> process-webpages macro in Lucene and Solr). This would also have the
> side-effect of Github formating them nicely on its web page.  Should I open
> an issue?
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: mikemcc...@apache.org [mailto:mikemcc...@apache.org]
> > Sent: Wednesday, July 5, 2017 5:01 PM
> > To: comm...@lucene.apache.org
> > Subject: lucene-solr:branch_7x: LUCENE-7899: add entry in MIGRATE.txt
> >
> > Repository: lucene-solr
> > Updated Branches:
> >   refs/heads/branch_7x f7ab77206 -> 084e5290e
> >
> >
> > LUCENE-7899: add entry in MIGRATE.txt
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/lucene-
> > solr/commit/084e5290
> > Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/084e5290
> > Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/084e5290
> >
> > Branch: refs/heads/branch_7x
> > Commit: 084e5290e1eb232ceba62f6361a0e2c6625dceaa
> > Parents: f7ab772
> > Author: Mike McCandless 
> > Authored: Wed Jul 5 10:56:39 2017 -0400
> > Committer: Mike McCandless 
> > Committed: Wed Jul 5 11:00:47 2017 -0400
> >
> > --
> >  lucene/MIGRATE.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/lucene-
> > solr/blob/084e5290/lucene/MIGRATE.txt
> > --
> > diff --git a/lucene/MIGRATE.txt b/lucene/MIGRATE.txt
> > index e7edcc5..e5e2822 100644
> > --- a/lucene/MIGRATE.txt
> > +++ b/lucene/MIGRATE.txt
> > @@ -144,3 +144,5 @@ can safely be casted to an int in that case.
> >
> >  Instead use ConcatentingTokenStream, which will allow for the use of
> > custom
> >  attributes.
> > +
> > +## FieldValueQuery is renamed to DocValuesFieldExistsQuery (LUCENE-
> > 7899)
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: JCC Segfault on Debian 9 (stretch)

[Joshua Campbell]

> But you should get a better stacktrace ?

I got the exact same stacktrace.

$ ldd
venv3/lib/python3.5/site-packages/JCC-3.0-py3.5-linux-x86_64.egg/libjcc3.so
linux-vdso.so.1 (0x7ffcf4eb8000)
libjava.so =>
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
(0x7f412227f000)
libjvm.so =>
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
(0x7f412133d000)
libpython3.5m.so.1.0 =>
/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 (0x7f4120c3a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f41208b8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f41205b4000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f412039b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f412017e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f411fddf000)
libverify.so =>
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libverify.so
(0x7f411fbce000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f411f9ca000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
(0x7f411f7a)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f411f584000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
(0x7f411f381000)
/lib64/ld-linux-x86-64.so.2 (0x55857b9dd000)

I did verify it's compiling with -g

x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -g
-fdebug-prefix-map=/build/python3.5-MLq5fN/python3.5-3.5.3=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -g -D_java_generics -DJCC_VER="3.0"
-I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include
-I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux -I_jcc3
-Ijcc3/sources -I/usr/include/python3.5m
-I/home/joshua/unnaturalcode/venv3/include/python3.5m -c
_jcc3/java/lang/String.cpp -o
build/temp.linux-x86_64-3.5/_jcc3/java/lang/String.o -DPYTHON
-fno-strict-aliasing -Wno-write-strings -O0 -g -DDEBUG

But it's still producing

Program received signal SIGSEGV, Segmentation fault.
0x7fffe47eb2b4 in ?? ()
(gdb) bt
#0  0x7fffe47eb2b4 in ?? ()
#1  0x0246 in ?? ()
#2  0x7fffe47eb160 in ?? ()
#3  0x7fffc840 in ?? ()
#4  0x7fffc7e0 in ?? ()
#5  0x76006075 in VM_Version::get_processor_features() ()
   from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)




On Wed, Jul 5, 2017 at 11:38 AM, Andi Vajda  wrote:

>
> On Jul 5, 2017, at 18:56, Joshua Campbell  wrote:
>
> >> What version if java is this jcc built with ?
> >> To build jcc for debugging with gcc add --debug to the build command.
> You
> > should then have symbols visible to gdb.
> >
> > You mean with setup.py build --debug ? I tried that on trunk and got the
> > same result.
>
> But you should get a better stacktrace ?
>
> >> Is the version of java used here the same as during jcc build time ?
> >
> > Yes I made sure of that and uninstalled all but openjdk and rebuilt.
>
> Did you verify this via running 'ldd' on the shared libraries involved ?
>
> That being said, it could be something different of course !
>
> Andi..
>
> >
> >> On Wed, Jul 5, 2017 at 10:46 AM, Andi Vajda  wrote:
> >>
> >>
> >>> On Jul 5, 2017, at 18:25, Joshua Campbell  wrote:
> >>>
> >>> This segfault appears to occur within the JVM code on both
> >> oracle-java8-jdk
> >>> and
> >>> java-1.8.0-openjdk-amd64. I installed the JVM debugging symbols but it
> >>> didn't seem to help.
> >>>
> >>> Occurs under python 2 and 3. I don't know how to debug this any
> further.
> >>>
> >>> 0 joshua@buttercup unnaturalcode 17609$ python3 -m virtualenv -p
> python3
> >>> venv3  Already using interpreter /usr/bin/python3
> >>> Using base prefix '/usr'
> >>> New python executable in /home/joshua/unnaturalcode/venv3/bin/python3
> >>> Also creating executable in /home/joshua/unnaturalcode/
> venv3/bin/python
> >>> Installing setuptools, pkg_resources, pip, wheel...done.
> >>> 0 joshua@buttercup unnaturalcode 17610$ source venv3/bin/activate
> >>> 0 joshua@buttercup unnaturalcode 17611$ which python
> >>> /home/joshua/unnaturalcode/venv3/bin/python
> >>> 0 joshua@buttercup unnaturalcode 17616$ pip install jcc --no-cache-dir
> >>> Collecting jcc
> >>> Downloading JCC-3.0.tar.gz (176kB)
> >>>   100% || 184kB 3.4MB/s
> >>> Installing collected packages: jcc
> >>> Running setup.py install for jcc ... done
> >>
> >> What version if java is this jcc built with ?
> >> To build jcc for debugging with gcc add --debug to the build command.
> You
> >> should then have symbols visible to gdb.
> >>
> >>> Successfully installed jcc-3.0
> >>> 0 joshua@buttercup unnaturalcode 17617$ gdb --args
> >>> 

[jira] [Commented] (LUCENE-7896) Upgrade to RandomizedRunner 2.5.2

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7896:
-

Thanks Simon.

> Upgrade to RandomizedRunner 2.5.2
> -
>
> Key: LUCENE-7896
> URL: https://issues.apache.org/jira/browse/LUCENE-7896
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Simon Willnauer
>Priority: Minor
> Fix For: 7.0, master (8.0)
>
> Attachments: LUCENE-7896.patch
>
>
> RR 2.5.2 fixed a nasty error message that gets printed while running tests 
> that is pretty annoying if you have the environment hitting this. Lets 
> upgrade to 2.5.2



--
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: JCC Segfault on Debian 9 (stretch)

[Andi Vajda]

On Jul 5, 2017, at 18:56, Joshua Campbell  wrote:

>> What version if java is this jcc built with ?
>> To build jcc for debugging with gcc add --debug to the build command. You
> should then have symbols visible to gdb.
> 
> You mean with setup.py build --debug ? I tried that on trunk and got the
> same result.

But you should get a better stacktrace ?

>> Is the version of java used here the same as during jcc build time ?
> 
> Yes I made sure of that and uninstalled all but openjdk and rebuilt.

Did you verify this via running 'ldd' on the shared libraries involved ?

That being said, it could be something different of course !

Andi..

> 
>> On Wed, Jul 5, 2017 at 10:46 AM, Andi Vajda  wrote:
>> 
>> 
>>> On Jul 5, 2017, at 18:25, Joshua Campbell  wrote:
>>> 
>>> This segfault appears to occur within the JVM code on both
>> oracle-java8-jdk
>>> and
>>> java-1.8.0-openjdk-amd64. I installed the JVM debugging symbols but it
>>> didn't seem to help.
>>> 
>>> Occurs under python 2 and 3. I don't know how to debug this any further.
>>> 
>>> 0 joshua@buttercup unnaturalcode 17609$ python3 -m virtualenv -p python3
>>> venv3  Already using interpreter /usr/bin/python3
>>> Using base prefix '/usr'
>>> New python executable in /home/joshua/unnaturalcode/venv3/bin/python3
>>> Also creating executable in /home/joshua/unnaturalcode/venv3/bin/python
>>> Installing setuptools, pkg_resources, pip, wheel...done.
>>> 0 joshua@buttercup unnaturalcode 17610$ source venv3/bin/activate
>>> 0 joshua@buttercup unnaturalcode 17611$ which python
>>> /home/joshua/unnaturalcode/venv3/bin/python
>>> 0 joshua@buttercup unnaturalcode 17616$ pip install jcc --no-cache-dir
>>> Collecting jcc
>>> Downloading JCC-3.0.tar.gz (176kB)
>>>   100% || 184kB 3.4MB/s
>>> Installing collected packages: jcc
>>> Running setup.py install for jcc ... done
>> 
>> What version if java is this jcc built with ?
>> To build jcc for debugging with gcc add --debug to the build command. You
>> should then have symbols visible to gdb.
>> 
>>> Successfully installed jcc-3.0
>>> 0 joshua@buttercup unnaturalcode 17617$ gdb --args
>>> /home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar
>> 
>> Is the version of java used here the same as during jcc build time ?
>> 
>> Andi..
>> 
>>> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
>>> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
>>> Copyright (C) 2016 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later > html
 
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show
>> copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> .
>>> Find the GDB manual and other documentation resources online at:
>>> .
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from /home/joshua/unnaturalcode/
>> venv3/bin/python...Reading
>>> symbols from
>>> /usr/lib/debug/.build-id/db/fc2e1a3c58b6d241b3f9af7b2fb3a2
>> 4b81b90e.debug...done.
>>> done.
>>> (gdb) r
>>> Starting program: /home/joshua/unnaturalcode/venv3/bin/python -m jcc
>> --jar
>>> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/x86_64-linux-gnu/
>> libthread_db.so.1".
>>> Installing openjdk unwinder
>>> Traceback (most recent call last):
>>> File
>>> "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/
>> jre/lib/amd64/server/
>>> libjvm.so-gdb.py", line 52, in 
>>>   class Types(object):
>>> File
>>> "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/
>> jre/lib/amd64/server/
>>> libjvm.so-gdb.py", line 66, in Types
>>>   nmethodp_t = gdb.lookup_type('nmethod').pointer()
>>> gdb.error: No type named nmethod.
>>> 
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x7fffe47f22b4 in ?? ()
>>> (gdb) bt
>>> #0  0x7fffe47f22b4 in ?? ()
>>> #1  0x0246 in ?? ()
>>> #2  0x7fffe47f2160 in ?? ()
>>> #3  0x7fffc8c0 in ?? ()
>>> #4  0x7fffc860 in ?? ()
>>> #5  0x7600d075 in VM_Version::get_processor_features() ()
>>>  from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/
>> server/libjvm.so
>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>> 
>>> 
>>> 
>>> --
>>> Joshua Charles Campbell
>>> Ph.D. Student and Research Assistant
>>> Department of Computing Science
>>> University of Alberta
>>> josh...@ualberta.ca
>> 
>> 
> 
> 
> -- 
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> 

[jira] [Updated] (SOLR-11014) server/solr-webapp/** missing for the eclipse exclusions in build.xml

[Antoine Le Floc'h (JIRA)]

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

Antoine Le Floc'h updated SOLR-11014:
-
Description: 
in the top folder, in build.xml
[https://github.com/apache/lucene-solr/blob/branch_6_6/build.xml]

in the "eclipse" target (line 442, branch_6_6)

{code:java}
   
  
  
  

{code}

Just like in the netbeans target, the fileset excluded should have 
"server/solr-webapp/**" also at the end.Otherwise, if I do "ant-eclipse" after 
"ant generate-maven-artifacts", i get eclipse errors like:
"The type FacetDoubleMerger is already defined  FacetModule.java
/solr6_/solr/core/src/java/org/apache/solr/search/facet line 364"

because

{code:java}

{code}

was included in my ".classpath" during the "ant-eclipse" phase.

So at the end of the line 

{code:java}

{code}


we should also add:

{code:java}

{code}

Thank you.

  was:
in the top folder, in build.xml
https://github.com/apache/lucene-solr/blob/branch_6_6/build.xml

in the "eclipse" target (line 442, branch_6_6)

   
  
  
  


Just like in the netbeans target, the fileset excluded should have 
"server/solr-webapp/**" also at the end.Otherwise, if I do "ant-eclipse" after 
"ant generate-maven-artifacts", i get eclipse errors like:
"The type FacetDoubleMerger is already defined  FacetModule.java
/solr6_/solr/core/src/java/org/apache/solr/search/facet line 364"

because
""
was included in my ".classpath" during the "ant-eclipse" phase.

So at the end of the line 
  

we should also add:
  

Thank you.


> server/solr-webapp/** missing for the eclipse exclusions in build.xml
> -
>
> Key: SOLR-11014
> URL: https://issues.apache.org/jira/browse/SOLR-11014
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 5.0, 6.0, 7.0
>Reporter: Antoine Le Floc'h
>Priority: Minor
>  Labels: build, easyfix
>
> in the top folder, in build.xml
> [https://github.com/apache/lucene-solr/blob/branch_6_6/build.xml]
> in the "eclipse" target (line 442, branch_6_6)
> {code:java}
>
>excludes="**/*servlet-api*.jar, analysis/uima/**, tools/**, build/**"/>
>includes="**/test-lib/*.jar,**/lib/*.jar" 
> excludes="core/test-lib/*servlet-api*.jar, contrib/analysis-extras/**, 
> test-framework/lib/junit*, test-framework/lib/ant*, 
> test-framework/lib/randomizedtesting*, build/**, dist/**, package/**" />
>   
> 
> {code}
> Just like in the netbeans target, the fileset excluded should have 
> "server/solr-webapp/**" also at the end.Otherwise, if I do "ant-eclipse" 
> after "ant generate-maven-artifacts", i get eclipse errors like:
> "The type FacetDoubleMerger is already definedFacetModule.java
> /solr6_/solr/core/src/java/org/apache/solr/search/facet line 364"
> because
> {code:java}
>  path="solr/server/solr-webapp/webapp/WEB-INF/lib/solr-core-6.6.0-SNAPSHOT.jar"/>
> {code}
> was included in my ".classpath" during the "ant-eclipse" phase.
> So at the end of the line 
> {code:java}
>  excludes="core/test-lib/*servlet-api*.jar, contrib/analysis-extras/**, 
> test-framework/lib/junit*, test-framework/lib/ant*, 
> test-framework/lib/randomizedtesting*, build/**, dist/**, package/**" />
> {code}
> we should also add:
> {code:java}
>  excludes="core/test-lib/*servlet-api*.jar, contrib/analysis-extras/**, 
> test-framework/lib/junit*, test-framework/lib/ant*, 
> test-framework/lib/randomizedtesting*, build/**, dist/**, package/**, 
> server/solr-webapp/**" />
> {code}
> Thank you.



--
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-9526) data_driven configs defaults to "strings" for unmapped fields, makes most fields containing "textual content" unsearchable, breaks tutorial examples

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-9526 at 7/5/17 5:36 PM:
--

Attaching patch brought up to date with master (in particular, collapsing of 
{{data_driven_schema_configs}} and {{basic_configs}} into {{_default}}) - note 
that your original patch only modified {{solrconfig.xml}} on one of these and 
{{managed_schema}} on the other - I assume you had/have local changes that 
didn't make it into the patch [~janhoy]?  I made a couple of other changes; 
details below.

{quote}
See new NOCOMMIT comments. I was using the ManagedIndexSchema method
{code}
public ManagedIndexSchema addCopyFields(String source, Collection 
destinations, int maxChars)
{code}
which does not have a {{persist=true/false}} argument, so calling it leaves the 
schema not persisted. Then I could not find a way to explicitly persist it 
since method
{{boolean persistManagedSchema(boolean createOnly)}}
was not public. In this patch I've made it public and done a hacky instanceof 
check in AddSchemaFieldsUpdateProcessorFactory
{code}
if (newSchema instanceof ManagedIndexSchema) {
  // NOCOMMIT: Hack to avoid persisting schema once after addFields and then 
once after each copyField
  ((ManagedIndexSchema)newSchema).persistManagedSchema(false);
}
{code}
Steve Rowe, you wrote the {{addCopyFields()}} method a while ago, is there a 
cleaner way to make sure schema is persisted after adding a copyField?
{quote}

The design of {{ManagedIndexSchema}}'s API was in support of the Schema REST 
API, where each resource was modifiable one at a time; "bulk" modifications 
weren't possible.  In the new bulk schema API, though, the ordinary case 
involves multiple modifications; in this case, it is counter-productive to 
persist in the middle of a set of operations.

SOLR-6476 (introducing schema "bulk" mode) added the option to *not* persist 
the schema after an operation; previously every operation was automatically 
persisted.  This was added as an option because at the time, bulk and REST 
modes co-existed.   SOLR-7682 added the ability to specify maxChars for 
copyField directives, and I intentionally left off the {{persist}} option of 
the new {{addCopyFields()}} method, because there was (intentionally) no way to 
invoke this capability via the (now deprecated) schema REST API, and the bulk 
schema API didn't need the {{persist}} option.

Long story short: I think making {{persistManagedSchema()}} public is a natural 
consequence of the bulk schema API (and in support of bulk operations from 
other sources, e.g. this issue).  It's just that nobody had gotten around to it 
yet.  

In {{AddSchemaFieldsUpdateProcessorFactory.processAdd()}} in my patch I removed 
the {{instanceof ManagedIndexSchema}} check wrapping the call to 
{{persistManagedSchama()}}, as well as the {{NOCOMMIT}}'s, since the check {{if 
( ! cmd.getReq().getSchema().isMutable())}} at the beginning of the method 
already ensures that we're dealing with a {{ManagedIndexSchema}}.

I also removed the following {{typeMapping}} that was added in your patch from 
URP chains {{add-fields-no-run-processor}} and {{parse-and-add-fields}} in 
{{solrconfig-add-schema-fields-update-processor-chains.xml}} - I'm assuming 
this is a vestige from an earlier concept of removing {{}}, 
since these chains have {{text}}?  
{{AddSchemaFieldsUpdateProcessorFactoryTest}} passes with my change:

{code:xml}

  java.lang.String
  text

{code}


was (Author: steve_rowe):
Attaching patch brought up to date with master (in particular, collapsing of 
{{data_driven_schema_configs}} and {{basic_configs}} into {{_default}}) - note 
that your original patch only modified {{solrconfig.xml}} on one of these and 
{{managed_schema}} on the other - I assume you had/have local changes that 
didn't make it into the patch [~janhoy]?  I made a couple of other changes; 
details below.

{quote}
See new NOCOMMIT comments. I was using the ManagedIndexSchema method
{code}
public ManagedIndexSchema addCopyFields(String source, Collection 
destinations, int maxChars)
{code}
which does not have a {{persist=true/false}} argument, so calling it leaves the 
schema not persisted. Then I could not find a way to explicitly persist it 
since method
{{boolean persistManagedSchema(boolean createOnly)}}
was not public. In this patch I've made it public and done a hacky instanceof 
check in AddSchemaFieldsUpdateProcessorFactory
{code}
if (newSchema instanceof ManagedIndexSchema) {
  // NOCOMMIT: Hack to avoid persisting schema once after addFields and then 
once after each copyField
  ((ManagedIndexSchema)newSchema).persistManagedSchema(false);
}
{code}
Steve Rowe, you wrote the {{addCopyFields()}} method a while ago, is there a 
cleaner way to make sure schema is persisted after adding a copyField?
{quote}

The design of 

[jira] [Created] (SOLR-11014) server/solr-webapp/** missing for the eclipse exclusions in build.xml

[Antoine Le Floc'h (JIRA)]

Antoine Le Floc'h created SOLR-11014:


 Summary: server/solr-webapp/** missing for the eclipse exclusions 
in build.xml
 Key: SOLR-11014
 URL: https://issues.apache.org/jira/browse/SOLR-11014
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Build
Affects Versions: 6.0, 5.0, 7.0
Reporter: Antoine Le Floc'h
Priority: Minor


in the top folder, in build.xml
https://github.com/apache/lucene-solr/blob/branch_6_6/build.xml

in the "eclipse" target (line 442, branch_6_6)

   
  
  
  


Just like in the netbeans target, the fileset excluded should have 
"server/solr-webapp/**" also at the end.Otherwise, if I do "ant-eclipse" after 
"ant generate-maven-artifacts", i get eclipse errors like:
"The type FacetDoubleMerger is already defined  FacetModule.java
/solr6_/solr/core/src/java/org/apache/solr/search/facet line 364"

because
""
was included in my ".classpath" during the "ant-eclipse" phase.

So at the end of the line 
  

we should also add:
  

Thank you.



--
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-9526) data_driven configs defaults to "strings" for unmapped fields, makes most fields containing "textual content" unsearchable, breaks tutorial examples

[Steve Rowe (JIRA)]

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

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

Attaching patch brought up to date with master (in particular, collapsing of 
{{data_driven_schema_configs}} and {{basic_configs}} into {{_default}}) - note 
that your original patch only modified {{solrconfig.xml}} on one of these and 
{{managed_schema}} on the other - I assume you had/have local changes that 
didn't make it into the patch [~janhoy]?  I made a couple of other changes; 
details below.

{quote}
See new NOCOMMIT comments. I was using the ManagedIndexSchema method
{code}
public ManagedIndexSchema addCopyFields(String source, Collection 
destinations, int maxChars)
{code}
which does not have a {{persist=true/false}} argument, so calling it leaves the 
schema not persisted. Then I could not find a way to explicitly persist it 
since method
{{boolean persistManagedSchema(boolean createOnly)}}
was not public. In this patch I've made it public and done a hacky instanceof 
check in AddSchemaFieldsUpdateProcessorFactory
{code}
if (newSchema instanceof ManagedIndexSchema) {
  // NOCOMMIT: Hack to avoid persisting schema once after addFields and then 
once after each copyField
  ((ManagedIndexSchema)newSchema).persistManagedSchema(false);
}
{code}
Steve Rowe, you wrote the {{addCopyFields()}} method a while ago, is there a 
cleaner way to make sure schema is persisted after adding a copyField?
{quote}

The design of {{ManagedIndexSchema}}'s API was in support of the Schema REST 
API, where each resource was modifiable one at a time; "bulk" modifications 
weren't possible.  In the new bulk schema API, though, the ordinary case 
involves multiple modifications; in this case, it is counter-productive to 
persist in the middle of a set of operations.

SOLR-6476 (introducing schema "bulk" mode) added the option to *not* persist 
the schema after an operation; previously every operation was automatically 
persisted.  This was added as an option because at the time, bulk and REST 
modes co-existed.   SOLR-7682 added the ability to specify maxChars for 
copyField directives, and I intentionally left off the {{persist}} option of 
the new {{addCopyFields()}} method, because there was (intentionally) no way to 
invoke this capability via the (now deprecated) schema REST API, and the bulk 
schema API didn't need the {{persist}} option.

Long story short: I think making {{persistManagedSchema()}} public is a natural 
consequence of the bulk schema API (and in support of bulk operations from 
other sources, e.g. this issue).  It's just that nobody had gotten around to it 
yet.  

In the {{AddSchemaFieldsUpdateProcessorFactory.processAdd()}} in my patch I 
removed the {{instanceof ManagedIndexSchema}} check wrapping the call to 
{{persistManagedSchama()}}, as well as the {{NOCOMMIT}}'s, since the check {{if 
( ! cmd.getReq().getSchema().isMutable())}} at the beginning of the method 
already insures that we're dealing with a {{ManagedIndexSchema}}.

I also removed the following {{typeMapping}} that was added in your patch from 
URP chains {{add-fields-no-run-processor}} and {{parse-and-add-fields}} in 
{{solrconfig-add-schema-fields-update-processor-chains.xml}} - I'm assuming 
this is a vestige from an earlier concept of removing {{}}, 
since these chains have {{text}}?  
{{AddSchemaFieldsUpdateProcessorFactoryTest}} passes with my change:

{code:xml}

  java.lang.String
  text

{code}

> data_driven configs defaults to "strings" for unmapped fields, makes most 
> fields containing "textual content" unsearchable, breaks tutorial examples
> 
>
> Key: SOLR-9526
> URL: https://issues.apache.org/jira/browse/SOLR-9526
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Reporter: Hoss Man
>Assignee: Jan Høydahl
>  Labels: dynamic-schema
> Fix For: 7.0
>
> Attachments: SOLR-9526.patch, SOLR-9526.patch, SOLR-9526.patch, 
> SOLR-9526.patch, SOLR-9526.patch
>
>
> James Pritchett pointed out on the solr-user list that this sample query from 
> the quick start tutorial matched no docs (even though the tutorial text says 
> "The above request returns only one document")...
> http://localhost:8983/solr/gettingstarted/select?wt=json=true=name:foundation
> The root problem seems to be that the add-unknown-fields-to-the-schema chain 
> in data_driven_schema_configs is configured with...
> {code}
> strings
> {code}
> ...and the "strings" type uses StrField and is not tokenized.
> 
> Original thread: 
> 

Re: JCC Segfault on Debian 9 (stretch)

[Joshua Campbell]

> What version if java is this jcc built with ?
Oh it's openjdk-8-dbg_8u131-b11-2

But I got a same result (the stacktrace was slightly different but still
undecoded) with Oracle's JDK.

On Wed, Jul 5, 2017 at 10:56 AM, Joshua Campbell 
wrote:

> > What version if java is this jcc built with ?
> > To build jcc for debugging with gcc add --debug to the build command.
> You should then have symbols visible to gdb.
>
> You mean with setup.py build --debug ? I tried that on trunk and got the
> same result.
>
> > Is the version of java used here the same as during jcc build time ?
>
> Yes I made sure of that and uninstalled all but openjdk and rebuilt.
>
> On Wed, Jul 5, 2017 at 10:46 AM, Andi Vajda  wrote:
>
>>
>> > On Jul 5, 2017, at 18:25, Joshua Campbell  wrote:
>> >
>> > This segfault appears to occur within the JVM code on both
>> oracle-java8-jdk
>> > and
>> > java-1.8.0-openjdk-amd64. I installed the JVM debugging symbols but it
>> > didn't seem to help.
>> >
>> > Occurs under python 2 and 3. I don't know how to debug this any further.
>> >
>> > 0 joshua@buttercup unnaturalcode 17609$ python3 -m virtualenv -p
>> python3
>> > venv3  Already using interpreter /usr/bin/python3
>> > Using base prefix '/usr'
>> > New python executable in /home/joshua/unnaturalcode/venv3/bin/python3
>> > Also creating executable in /home/joshua/unnaturalcode/venv3/bin/python
>> > Installing setuptools, pkg_resources, pip, wheel...done.
>> > 0 joshua@buttercup unnaturalcode 17610$ source venv3/bin/activate
>> > 0 joshua@buttercup unnaturalcode 17611$ which python
>> > /home/joshua/unnaturalcode/venv3/bin/python
>> > 0 joshua@buttercup unnaturalcode 17616$ pip install jcc --no-cache-dir
>> > Collecting jcc
>> >  Downloading JCC-3.0.tar.gz (176kB)
>> >100% || 184kB 3.4MB/s
>> > Installing collected packages: jcc
>> >  Running setup.py install for jcc ... done
>>
>> What version if java is this jcc built with ?
>> To build jcc for debugging with gcc add --debug to the build command. You
>> should then have symbols visible to gdb.
>>
>> > Successfully installed jcc-3.0
>> > 0 joshua@buttercup unnaturalcode 17617$ gdb --args
>> > /home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar
>>
>> Is the version of java used here the same as during jcc build time ?
>>
>> Andi..
>>
>> > java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
>> > GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
>> > Copyright (C) 2016 Free Software Foundation, Inc.
>> > License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html
>> >>
>> > This is free software: you are free to change and redistribute it.
>> > There is NO WARRANTY, to the extent permitted by law.  Type "show
>> copying"
>> > and "show warranty" for details.
>> > This GDB was configured as "x86_64-linux-gnu".
>> > Type "show configuration" for configuration details.
>> > For bug reporting instructions, please see:
>> > .
>> > Find the GDB manual and other documentation resources online at:
>> > .
>> > For help, type "help".
>> > Type "apropos word" to search for commands related to "word"...
>> > Reading symbols from /home/joshua/unnaturalcode/ven
>> v3/bin/python...Reading
>> > symbols from
>> > /usr/lib/debug/.build-id/db/fc2e1a3c58b6d241b3f9af7b2fb3a24b
>> 81b90e.debug...done.
>> > done.
>> > (gdb) r
>> > Starting program: /home/joshua/unnaturalcode/venv3/bin/python -m jcc
>> --jar
>> > java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
>> > [Thread debugging using libthread_db enabled]
>> > Using host libthread_db library "/lib/x86_64-linux-gnu/libthre
>> ad_db.so.1".
>> > Installing openjdk unwinder
>> > Traceback (most recent call last):
>> >  File
>> > "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/j
>> re/lib/amd64/server/
>> > libjvm.so-gdb.py", line 52, in 
>> >class Types(object):
>> >  File
>> > "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/j
>> re/lib/amd64/server/
>> > libjvm.so-gdb.py", line 66, in Types
>> >nmethodp_t = gdb.lookup_type('nmethod').pointer()
>> > gdb.error: No type named nmethod.
>> >
>> > Program received signal SIGSEGV, Segmentation fault.
>> > 0x7fffe47f22b4 in ?? ()
>> > (gdb) bt
>> > #0  0x7fffe47f22b4 in ?? ()
>> > #1  0x0246 in ?? ()
>> > #2  0x7fffe47f2160 in ?? ()
>> > #3  0x7fffc8c0 in ?? ()
>> > #4  0x7fffc860 in ?? ()
>> > #5  0x7600d075 in VM_Version::get_processor_features() ()
>> >   from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/
>> libjvm.so
>> > Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>> >
>> >
>> >
>> > --
>> > Joshua Charles Campbell
>> > Ph.D. Student and Research Assistant
>> > Department of Computing Science
>> > University of Alberta
>> > josh...@ualberta.ca
>>
>>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and 

RE: 10 Resource Leak warnings dated to Q2 2017

[Uwe Schindler]

If we use the -Werror flag be sure to NOT enable all warnings and disable some 
of them (this makes build non-reproducible if JVM changes). So when using 
-Werror, we should list all warnings we want to see explicit (so no “all” 
warning). For Eclipse’s ECJ do the same.

 

In general with the Eclipse compiler we can define “per violation type” which 
action to take (warn or fail). But unfortunately, this does not allow 
suppression (as it is no longer a warning).

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: md...@cloudera.com [mailto:md...@cloudera.com] On Behalf Of Mike Drob
Sent: Wednesday, July 5, 2017 6:10 PM
To: Lucene Dev 
Cc: Christine Poerschke 
Subject: Re: 10 Resource Leak warnings dated to Q2 2017

 

I think you can do this with the -Werror flag and supress annotating everything 
else.

 

On Wed, Jul 5, 2017 at 10:45 AM, Erick Erickson  > wrote:

bq:  making precommit fail for some but not all resource leaks.
Implementation wise, how might one go about that?

No clue, hoping somebody who _does_ have clue will just say "oh, you
just specify blah blah blah" ;)

On Wed, Jul 5, 2017 at 8:39 AM, Christine Poerschke (BLOOMBERG/

LONDON)  > wrote:
> Hi Erick,
>
> Thanks for the extra context re: JavaBinCodec and SOLR-10779.
>
> I agree that backporting warning fixes to 6x is optional at this point and 
> for complex fixes probably not worth the risk of introducing subtle bugs in 
> the process.
>
> +1 to your idea of making precommit fail for some but not all resource leaks. 
> Implementation wise, how might one go about that? Redirecting precommit 
> output and post-processing it should be do-able but seems hacky ...
>
> Christine
>
> - Original Message -
> From: dev@lucene.apache.org  
> To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org 
>  
> At: 07/04/17 16:45:11
>
> Christine:
>
> I fixed the JavaBinCodec warnings in SOLR-10779 for master/7.0, but
> didn't backport to 6x. So if those warnings are creeping back in to
> the 7x code line we can take a look.
>
> I didn't backport to 6x since this seems to be long-term enough that
> there isn't much point, along with the feeling that we'll introduce
> problems at times in the effort and my view is that 6x is close enough
> to end of development that we shouldn't expend the effort or introduce
> instabilities. Or, put another way, I didn't want to be responsible
> for introducing bugs in 6x, 7x is fair game ;)
>
> Along the lines of making forward progress though Is it possible
> to make precommit fail for resource leaks for specific classes only?
> Or for specific files? It wouldn't be perfect, but cleaning up
> warnings for a class then having precommit fail if resource leaks came
> back in would feel less like Sisyphus.
>
> I'm looking for either of the following. Or both of course.
> - fail if precommit issues resource leak warnings for the _class_
> JavaBinCodec wherever it's used.
> - fail if precommit issues resource leak warnings in the _file_
> whatever.java if any resource leak warnings are found for any class.
>
> The first one is the one I'd probably use on the theory that one gets
> familiar with the quirks of a particular class and it's easier to
> clean up the resource leak warnings for that class than all the
> warnings that might be in a file. But that's a personal preference.
>
> Erick
>
> On Tue, Jul 4, 2017 at 3:47 AM, Christine Poerschke (BLOOMBERG/
> LONDON)  > wrote:
>> Hi Everyone,
>>
>> The following list is the latest Q2 2017 portion of the dated-warnings.log 
>> file I've attached to https://issues.apache.org/jira/browse/SOLR-10778 and 
>> it was generated by the also attached shell script that correlates warnings 
>> with git commit history.
>>
>> Any help to investigate and take care of these warnings would be 
>> appreciated. The short term goal is to not increase the number of warnings 
>> we have and in the medium to long term the goal would be to fail precommit 
>> if any warnings are detected.
>>
>> Christine
>>
>> PS: @SuppressWarnings("resource") can be used to suppress inappropriate 
>> warnings and Erick Erickson is already looking into warnings related to 
>> JavaBinCodec.
>>
>> -
>>  ant precommit warnings dated to Q2 2017
>> -
>>
>> 2017-06-21 
>> http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/ReadersAndUpdates.java#L845
>> 2017-06-21 
>> http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java#L186
>> 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6710/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:52640/_jd/ml

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:52640/_jd/ml
at 
__randomizedtesting.SeedInfo.seed([9BDAEAA95EBDCA83:138ED573F041A77B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
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.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1667)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1694)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:254)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

Re: Feature freeze @ 7.0 branch

[Anshum Gupta]

I think most of us want to get a bunch of stuff in for the 7.0 release, so it 
would make sense for us to open up 7.0 ONLY for improvements (code/usability), 
deprecations, and bug fixes for the rest of this week. I would request that all 
of us wrap everything but blocker bug fixes by the end of this week i.e. 
Sunday, July 9th. We need to do this so we can move ahead and wrap up the real 
blockers. For stuff that doesn’t make it into our repo by that date (and isn’t 
a blocker), there would be a 7.1 :).

Does that sound reasonable to everyone ?

P.S: Please keep the JIRAs updated so everyone else knows what we’re pushing 
in. Also, in case of usability changes, we should remember fixing the ref guide 
(where applicable).

-Anshum



> On Jul 5, 2017, at 9:46 AM, Varun Thacker  wrote:
> 
> Hi Anshum,
> 
> I'd like to get SOLR-10967 in as well. It contains some changes to the 
> default configset and no code changes.
> 
> 
> On Wed, Jul 5, 2017 at 8:06 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
> > wrote:
> I'd like to see https://issues.apache.org/jira/browse/SOLR-10985 
>  included in 7.0 since it's 
> a small low-risk change but it being in cache classes will benefit many users.
> 
> Christine
> 
> From: dev@lucene.apache.org  At: 07/05/17 
> 16:00:48
> To: dev@lucene.apache.org 
> Subject: Re: Feature freeze @ 7.0 branch
> Sure Mikhail, and Mike.
> 
> -Anshum
> 
> 
> 
>> On Jul 5, 2017, at 5:09 AM, Mikhail Khludnev > > wrote:
>> 
>> Is it worth to push https://issues.apache.org/jira/browse/SOLR-10986 
>>  fixes regression in 
>> https://issues.apache.org/jira/browse/SOLR-6357 
>>  into 7.0?  
>> 
>> On Wed, Jul 5, 2017 at 12:48 PM, Michael McCandless 
>> > wrote:
>> Hi Anshum, I'd like to do https://issues.apache.org/jira/browse/LUCENE-7899 
>>  for 7.0; it's a simple 
>> rename, which I think we should do on major release.  I'll get a patch up 
>> shortly.
>> 
>> Thanks,
>> 
>> Mike McCandless
>> 
>> http://blog.mikemccandless.com 
>> 
>> On Tue, Jul 4, 2017 at 12:40 PM, Anshum Gupta > > wrote:
>> Sure Ab, this is an important bug fix.
>> 
>> -Anshum
>> 
>> On Tue, Jul 4, 2017 at 9:35 AM Andrzej Białecki 
>> > 
>> wrote:
>> SOLR-10878 and SOLR-10879 didn’t make it before the branches were cut, but I 
>> think they should be included in 7x and 7_0 - I’m going to cherry-pick the 
>> commits from master.
>> 
>>> On 3 Jul 2017, at 22:29, Anshum Gupta >> > wrote:
>>> 
>>> Hi,
>>> 
>>> I just wanted to call it out and remove any confusions around the fact that 
>>> we shouldn’t we committing ‘new features’ to branch_7_0. As far as whatever 
>>> was already agreed upon in previous communications, let’s get that stuff in 
>>> if it’s ready or almost there. For everything else, kindly check before you 
>>> commit to the release branch.
>>> 
>>> Let us make sure that the bugs and edge cases are all taken care of, the 
>>> deprecations, and cleanups too.
>>> 
>>> P.S: Feel free to commit bug fixes without checking, but make sure that we 
>>> aren’t hiding features in those commits.
>>> 
>>> 
>>> -Anshum
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Sincerely yours
>> Mikhail Khludnev
> 
> 

[jira] [Commented] (SOLR-11013) remove /v2/c alias in favour of /v2/collections only

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11013:
--

Since it's marked as an experimental feature we could say that {{/v2/c}} has 
been removed in favour of the already existing {{/v2/collections}} endpoint?

> remove /v2/c alias in favour of /v2/collections only
> 
>
> Key: SOLR-11013
> URL: https://issues.apache.org/jira/browse/SOLR-11013
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11013.patch
>
>
> (Perhaps this has already been considered previously elsewhere or on the 
> mailing list and I just missed it then and couldn't find it now, in which 
> case happy to withdraw this ticket.)
> Would like propose that {{/v2/c}} be removed in favour of {{/v2/collections}} 
> only:
> * there being two ways to do the same thing is potentially confusing
> * {{/v2/c}} is short but _c_ could stand not only for _collections_ but also 
> for _cores_ or _cluster_ or _config_ or _cloud_ etc.



--
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: JCC Segfault on Debian 9 (stretch)

[Joshua Campbell]

> What version if java is this jcc built with ?
> To build jcc for debugging with gcc add --debug to the build command. You
should then have symbols visible to gdb.

You mean with setup.py build --debug ? I tried that on trunk and got the
same result.

> Is the version of java used here the same as during jcc build time ?

Yes I made sure of that and uninstalled all but openjdk and rebuilt.

On Wed, Jul 5, 2017 at 10:46 AM, Andi Vajda  wrote:

>
> > On Jul 5, 2017, at 18:25, Joshua Campbell  wrote:
> >
> > This segfault appears to occur within the JVM code on both
> oracle-java8-jdk
> > and
> > java-1.8.0-openjdk-amd64. I installed the JVM debugging symbols but it
> > didn't seem to help.
> >
> > Occurs under python 2 and 3. I don't know how to debug this any further.
> >
> > 0 joshua@buttercup unnaturalcode 17609$ python3 -m virtualenv -p python3
> > venv3  Already using interpreter /usr/bin/python3
> > Using base prefix '/usr'
> > New python executable in /home/joshua/unnaturalcode/venv3/bin/python3
> > Also creating executable in /home/joshua/unnaturalcode/venv3/bin/python
> > Installing setuptools, pkg_resources, pip, wheel...done.
> > 0 joshua@buttercup unnaturalcode 17610$ source venv3/bin/activate
> > 0 joshua@buttercup unnaturalcode 17611$ which python
> > /home/joshua/unnaturalcode/venv3/bin/python
> > 0 joshua@buttercup unnaturalcode 17616$ pip install jcc --no-cache-dir
> > Collecting jcc
> >  Downloading JCC-3.0.tar.gz (176kB)
> >100% || 184kB 3.4MB/s
> > Installing collected packages: jcc
> >  Running setup.py install for jcc ... done
>
> What version if java is this jcc built with ?
> To build jcc for debugging with gcc add --debug to the build command. You
> should then have symbols visible to gdb.
>
> > Successfully installed jcc-3.0
> > 0 joshua@buttercup unnaturalcode 17617$ gdb --args
> > /home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar
>
> Is the version of java used here the same as during jcc build time ?
>
> Andi..
>
> > java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
> > GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later  html
> >>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /home/joshua/unnaturalcode/
> venv3/bin/python...Reading
> > symbols from
> > /usr/lib/debug/.build-id/db/fc2e1a3c58b6d241b3f9af7b2fb3a2
> 4b81b90e.debug...done.
> > done.
> > (gdb) r
> > Starting program: /home/joshua/unnaturalcode/venv3/bin/python -m jcc
> --jar
> > java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/x86_64-linux-gnu/
> libthread_db.so.1".
> > Installing openjdk unwinder
> > Traceback (most recent call last):
> >  File
> > "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/
> jre/lib/amd64/server/
> > libjvm.so-gdb.py", line 52, in 
> >class Types(object):
> >  File
> > "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/
> jre/lib/amd64/server/
> > libjvm.so-gdb.py", line 66, in Types
> >nmethodp_t = gdb.lookup_type('nmethod').pointer()
> > gdb.error: No type named nmethod.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x7fffe47f22b4 in ?? ()
> > (gdb) bt
> > #0  0x7fffe47f22b4 in ?? ()
> > #1  0x0246 in ?? ()
> > #2  0x7fffe47f2160 in ?? ()
> > #3  0x7fffc8c0 in ?? ()
> > #4  0x7fffc860 in ?? ()
> > #5  0x7600d075 in VM_Version::get_processor_features() ()
> >   from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/
> server/libjvm.so
> > Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> >
> >
> >
> > --
> > Joshua Charles Campbell
> > Ph.D. Student and Research Assistant
> > Department of Computing Science
> > University of Alberta
> > josh...@ualberta.ca
>
>


-- 
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca

[jira] [Updated] (SOLR-11013) remove /v2/c alias in favour of /v2/collections only

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11013:
---
Attachment: SOLR-11013.patch

Attaching proposed patch, tests seem to pass with these changes, not sure on 
how any documentation or CHANGES.txt wording would have to be given that 
{{v2/c}} is already out there?

> remove /v2/c alias in favour of /v2/collections only
> 
>
> Key: SOLR-11013
> URL: https://issues.apache.org/jira/browse/SOLR-11013
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11013.patch
>
>
> (Perhaps this has already been considered previously elsewhere or on the 
> mailing list and I just missed it then and couldn't find it now, in which 
> case happy to withdraw this ticket.)
> Would like propose that {{/v2/c}} be removed in favour of {{/v2/collections}} 
> only:
> * there being two ways to do the same thing is potentially confusing
> * {{/v2/c}} is short but _c_ could stand not only for _collections_ but also 
> for _cores_ or _cluster_ or _config_ or _cloud_ etc.



--
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-11013) remove /v2/c alias in favour of /v2/collections only

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-11013:
--

 Summary: remove /v2/c alias in favour of /v2/collections only
 Key: SOLR-11013
 URL: https://issues.apache.org/jira/browse/SOLR-11013
 Project: Solr
  Issue Type: Wish
Reporter: Christine Poerschke
Priority: Minor


(Perhaps this has already been considered previously elsewhere or on the 
mailing list and I just missed it then and couldn't find it now, in which case 
happy to withdraw this ticket.)

Would like propose that {{/v2/c}} be removed in favour of {{/v2/collections}} 
only:
* there being two ways to do the same thing is potentially confusing
* {{/v2/c}} is short but _c_ could stand not only for _collections_ but also 
for _cores_ or _cluster_ or _config_ or _cloud_ etc.



--
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: JCC Segfault on Debian 9 (stretch)

[Andi Vajda]

> On Jul 5, 2017, at 18:25, Joshua Campbell  wrote:
> 
> This segfault appears to occur within the JVM code on both oracle-java8-jdk
> and
> java-1.8.0-openjdk-amd64. I installed the JVM debugging symbols but it
> didn't seem to help.
> 
> Occurs under python 2 and 3. I don't know how to debug this any further.
> 
> 0 joshua@buttercup unnaturalcode 17609$ python3 -m virtualenv -p python3
> venv3  Already using interpreter /usr/bin/python3
> Using base prefix '/usr'
> New python executable in /home/joshua/unnaturalcode/venv3/bin/python3
> Also creating executable in /home/joshua/unnaturalcode/venv3/bin/python
> Installing setuptools, pkg_resources, pip, wheel...done.
> 0 joshua@buttercup unnaturalcode 17610$ source venv3/bin/activate
> 0 joshua@buttercup unnaturalcode 17611$ which python
> /home/joshua/unnaturalcode/venv3/bin/python
> 0 joshua@buttercup unnaturalcode 17616$ pip install jcc --no-cache-dir
> Collecting jcc
>  Downloading JCC-3.0.tar.gz (176kB)
>100% || 184kB 3.4MB/s
> Installing collected packages: jcc
>  Running setup.py install for jcc ... done

What version if java is this jcc built with ?
To build jcc for debugging with gcc add --debug to the build command. You 
should then have symbols visible to gdb.

> Successfully installed jcc-3.0
> 0 joshua@buttercup unnaturalcode 17617$ gdb --args
> /home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar

Is the version of java used here the same as during jcc build time ?

Andi..

> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later > 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /home/joshua/unnaturalcode/venv3/bin/python...Reading
> symbols from
> /usr/lib/debug/.build-id/db/fc2e1a3c58b6d241b3f9af7b2fb3a24b81b90e.debug...done.
> done.
> (gdb) r
> Starting program: /home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar
> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Installing openjdk unwinder
> Traceback (most recent call last):
>  File
> "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/
> libjvm.so-gdb.py", line 52, in 
>class Types(object):
>  File
> "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/
> libjvm.so-gdb.py", line 66, in Types
>nmethodp_t = gdb.lookup_type('nmethod').pointer()
> gdb.error: No type named nmethod.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffe47f22b4 in ?? ()
> (gdb) bt
> #0  0x7fffe47f22b4 in ?? ()
> #1  0x0246 in ?? ()
> #2  0x7fffe47f2160 in ?? ()
> #3  0x7fffc8c0 in ?? ()
> #4  0x7fffc860 in ?? ()
> #5  0x7600d075 in VM_Version::get_processor_features() ()
>   from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> 
> 
> -- 
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> josh...@ualberta.ca

Re: Feature freeze @ 7.0 branch

[Varun Thacker]

Hi Anshum,

I'd like to get SOLR-10967 in as well. It contains some changes to the
default configset and no code changes.


On Wed, Jul 5, 2017 at 8:06 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> I'd like to see https://issues.apache.org/jira/browse/SOLR-10985 included
> in 7.0 since it's a small low-risk change but it being in cache classes
> will benefit many users.
>
> Christine
>
> From: dev@lucene.apache.org At: 07/05/17 16:00:48
> To: dev@lucene.apache.org
> Subject: Re: Feature freeze @ 7.0 branch
>
> Sure Mikhail, and Mike.
>
> -Anshum
>
>
>
> On Jul 5, 2017, at 5:09 AM, Mikhail Khludnev  wrote:
>
> Is it worth to push https://issues.apache.org/jira/browse/SOLR-10986
> fixes regression in https://issues.apache.org/jira/browse/SOLR-6357 into
> 7.0?
>
> On Wed, Jul 5, 2017 at 12:48 PM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> Hi Anshum, I'd like to do https://issues.apache.org/
>> jira/browse/LUCENE-7899 for 7.0; it's a simple rename, which I think we
>> should do on major release.  I'll get a patch up shortly.
>>
>> Thanks,
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Tue, Jul 4, 2017 at 12:40 PM, Anshum Gupta 
>> wrote:
>>
>>> Sure Ab, this is an important bug fix.
>>>
>>> -Anshum
>>>
>>> On Tue, Jul 4, 2017 at 9:35 AM Andrzej Białecki <
>>> andrzej.biale...@lucidworks.com> wrote:
>>>
 SOLR-10878 and SOLR-10879 didn’t make it before the branches were cut,
 but I think they should be included in 7x and 7_0 - I’m going to
 cherry-pick the commits from master.

 On 3 Jul 2017, at 22:29, Anshum Gupta  wrote:

 Hi,

 I just wanted to call it out and remove any confusions around the fact
 that we shouldn’t we committing ‘new features’ to branch_7_0. As far as
 whatever was already agreed upon in previous communications, let’s get that
 stuff in if it’s ready or almost there. For everything else, kindly check
 before you commit to the release branch.

 Let us make sure that the bugs and edge cases are all taken care of,
 the deprecations, and cleanups too.

 P.S: Feel free to commit bug fixes without checking, but make sure that
 we aren’t hiding features in those commits.


 -Anshum





>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
>
>