[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 167 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/167/

12 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testBufferOnNonLeader

Error Message:
Captured an uncaught exception in thread: Thread[id=13573, 
name=qtp1761041527-13573, state=RUNNABLE, 
group=TGRP-CdcrReplicationDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=13573, name=qtp1761041527-13573, state=RUNNABLE, 
group=TGRP-CdcrReplicationDistributedZkTest]
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at __randomizedtesting.SeedInfo.seed([ACC2C663FAC26076]:0)
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.startThreads(QueuedThreadPool.java:462)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.access$200(QueuedThreadPool.java:47)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:639)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.cloud.TestRequestStatusCollectionAPI.test

Error Message:
Multiple exceptions

Stack Trace:
MultiException[java.lang.OutOfMemoryError: unable to create new native thread, 
java.util.concurrent.RejectedExecutionException: 
org.eclipse.jetty.io.ManagedSelector@6d878f23 id=0 keys=0 selected=0]
at 
__randomizedtesting.SeedInfo.seed([ACC2C663FAC26076:2496F9B9543E0D8E]:0)
at org.eclipse.jetty.server.Server.doStart(Server.java:347)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:342)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:315)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJetty(AbstractFullDistribZkTestBase.java:510)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:399)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:332)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:990)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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)

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_102) - Build # 6143 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6143/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 10935 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\temp\junit4-J0-20160928_012801_874.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # There is insufficient memory for the Java Runtime Environment to 
continue.
   [junit4] # Native memory allocation (malloc) failed to allocate 559864 bytes 
for Chunk::new
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\hs_err_pid11216.log
   [junit4] #
   [junit4] # Compiler replay data is saved as:
   [junit4] # 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\replay_pid11216.log
   [junit4] <<< JVM J0: EOF 

[...truncated 1325 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
C:\Users\jenkins\tools\java\32bit\jdk1.8.0_102\jre\bin\java.exe -server 
-XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\heapdumps
 -ea -esa -Dtests.prefix=tests -Dtests.seed=3C6E7426838832EA -Xmx512M 
-Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
-Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=7.0.0 -Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\tools\junit4\logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\temp
 -Dcommon.dir=C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene 
-Dclover.db.dir=C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\clover\db
 
-Djava.security.policy=C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\tools\junit4\solr-tests.policy
 -Dtests.LUCENE_VERSION=7.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Djunit4.childvm.cwd=C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0
 -Djunit4.childvm.id=0 -Djunit4.childvm.count=2 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true -Dtests.disableHdfs=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=UTF-8 -classpath 

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9570:
--

Reasonable points, although I can quibble about whether there should ever be 
System.out.println calls anywhere. I suppose there are some situations where we 
may want to give feedback before the logging stuff is initialized.

I can report from "in the field" that more than one client has run out of disk 
space because the CONSOLE log grew without bound. That's taken care of 
recently, so just as long as we keep it so ;)

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9575) Initialize an empty solr-home

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9575:
--

+1 to Hoss' idea. I also would rather fail than do things under the covers.

If it addresses the basic concern I think it's a _much_ better idea than 
creating the SOLR_HOME dir automagically.

> Initialize an empty solr-home
> -
>
> Key: SOLR-9575
> URL: https://issues.apache.org/jira/browse/SOLR-9575
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>
> The user may not want to use Solr's default solr-home dir location -- most 
> likely to use a separate disk.  If you do this, there are two main problems:
> * solr.xml & zoo.cfg aren't there
> * configsets aren't there
> Of course you could copy it manually but that's an extra step, and it's 
> particularly annoying to add this step to a Docker setup.  Docker is all the 
> rage these days, and for good reason.  If I mount a volume at 
> /opt/solr/server/solr then it basically masks this part of the built-in Solr 
> image (thus making configsets completely invisible) and points to some place 
> that will be empty.  Solr obviously complains.  I could set the solr-home to 
> some other path that I mount, but Solr would still complain about an empty 
> solr-home -- no solr.xml
> If solr-home is empty, and if it's a dir other than the default solr-home, 
> then I think the solr-home should be initialized with solr.xml and zoo.cfg 
> copied from the default solr-home.  I think configsets should be referenced 
> from the default solr-home if there is no configsets dir in solr-home.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-8146:
-

Hello Noble,

Can you please review the pull request and provide feedback on the approach of 
implementing routingRule and accordingly i can move forward with it.

Thanks,
Susheel

> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9575) Initialize an empty solr-home

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9575:


bq. If solr-home is empty, and if it's a dir other than the default solr-home, 
then I think the solr-home should be initialized with solr.xml and zoo.cfg 
copied from the default solr-home.

-1

As a general pattern, the idea that "directory X is empty, (or non-existent) 
therefore solr should fill it in with defaults" is dangerous because it leads 
to situations where people make mistakes during installation and configure/run 
solr with the wrong paths (typo, mistaken understanding of what dir they need, 
etc) and there is no obvious feedback that something is wrong.

I'd much rather see us add a {{bin/solr init-home 
/some/dir/that/is/empty/or/does/not/exist}} command that copies the suggested 
defaults over then have it happen automagically

(see for example SOLR-8649 where there is a discussion of the merits of moving 
*away* from automagically creating paths in ZK because people run into exactly 
this type of mistake with ZK chroot directory mistakes)


> Initialize an empty solr-home
> -
>
> Key: SOLR-9575
> URL: https://issues.apache.org/jira/browse/SOLR-9575
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>
> The user may not want to use Solr's default solr-home dir location -- most 
> likely to use a separate disk.  If you do this, there are two main problems:
> * solr.xml & zoo.cfg aren't there
> * configsets aren't there
> Of course you could copy it manually but that's an extra step, and it's 
> particularly annoying to add this step to a Docker setup.  Docker is all the 
> rage these days, and for good reason.  If I mount a volume at 
> /opt/solr/server/solr then it basically masks this part of the built-in Solr 
> image (thus making configsets completely invisible) and points to some place 
> that will be empty.  Solr obviously complains.  I could set the solr-home to 
> some other path that I mount, but Solr would still complain about an empty 
> solr-home -- no solr.xml
> If solr-home is empty, and if it's a dir other than the default solr-home, 
> then I think the solr-home should be initialized with solr.xml and zoo.cfg 
> copied from the default solr-home.  I think configsets should be referenced 
> from the default solr-home if there is no configsets dir in solr-home.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

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

Jan Høydahl commented on SOLR-9570:
---

Another option is to log stdout/err to the System log. In Linux that can be 
done by piping {{java ... 2>&1 | logger}}. Personally I like a plain file 
better...

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9575) Initialize an empty solr-home

[JIRA]

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

Jan Høydahl commented on SOLR-9575:
---

+1

> Initialize an empty solr-home
> -
>
> Key: SOLR-9575
> URL: https://issues.apache.org/jira/browse/SOLR-9575
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>
> The user may not want to use Solr's default solr-home dir location -- most 
> likely to use a separate disk.  If you do this, there are two main problems:
> * solr.xml & zoo.cfg aren't there
> * configsets aren't there
> Of course you could copy it manually but that's an extra step, and it's 
> particularly annoying to add this step to a Docker setup.  Docker is all the 
> rage these days, and for good reason.  If I mount a volume at 
> /opt/solr/server/solr then it basically masks this part of the built-in Solr 
> image (thus making configsets completely invisible) and points to some place 
> that will be empty.  Solr obviously complains.  I could set the solr-home to 
> some other path that I mount, but Solr would still complain about an empty 
> solr-home -- no solr.xml
> If solr-home is empty, and if it's a dir other than the default solr-home, 
> then I think the solr-home should be initialized with solr.xml and zoo.cfg 
> copied from the default solr-home.  I think configsets should be referenced 
> from the default solr-home if there is no configsets dir in solr-home.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9411) Better validation of fields and dynamic fields for Schema API

[Steve Rowe (JIRA)]

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

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

> Better validation of fields and dynamic fields for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Steve Rowe
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411-part2.patch, SOLR-9411-part2.patch, 
> SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9411) Better validation of fields and dynamic fields for Schema API

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9411: Better validation for Schema API add-field


> Better validation of fields and dynamic fields for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Steve Rowe
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411-part2.patch, SOLR-9411-part2.patch, 
> SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9411) Better validation of fields and dynamic fields for Schema API

[ASF subversion and git services (JIRA)]

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

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

Commit 49c5a749c3e95d33ca338331a270633503fe8ff7 in lucene-solr's branch 
refs/heads/branch_6x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=49c5a74 ]

SOLR-9411: Better validation for Schema API add-field


> Better validation of fields and dynamic fields for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Steve Rowe
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411-part2.patch, SOLR-9411-part2.patch, 
> SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9570:


bq. The file is useful since it will capture any errors happening outside of 
the logging system

Good point, and I did not think of that.

If we'll always be attempting to mute log4j's CONSOLE output when in background 
mode, perhaps we can let the console log grow, because it will not normally get 
much output.  Alternately we could rotate it through a simple fixed set of 10 
filenames, changing a single 0-9 digit ... so there would be history for 
several start attempts.


> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9411) Better validation of fields and dynamic fields for Schema API

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9411:
-
Attachment: SOLR-9411-part2.patch

Slight modification to an existing test in TestBulkSchemaAPI, since the error 
message for invalid "add-field" changed with the switch to 
IndexSchema.newField(). Also modified CHANGES.txt entry.

Tests and precommit pass with this patch. Committing shortly.

> Better validation of fields and dynamic fields for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Steve Rowe
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411-part2.patch, SOLR-9411-part2.patch, 
> SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9411) Better validation of fields and dynamic fields for Schema API

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9411:
-
Summary: Better validation of fields and dynamic fields for Schema API  
(was: Better validation of dynamic field for Schema API)

> Better validation of fields and dynamic fields for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Steve Rowe
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411-part2.patch, SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (SOLR-9411) Better validation of dynamic field for Schema API

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9411:
--
  Assignee: Steve Rowe  (was: Jan Høydahl)

Reopening to commit my patch.

> Better validation of dynamic field for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Steve Rowe
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411-part2.patch, SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Apache Jenkins Server]

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=10703, 
name=OverseerHdfsCoreFailoverThread-9288999301125-127.0.0.1:35056_qzk%2Fov-n_00,
 state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=10703, 
name=OverseerHdfsCoreFailoverThread-9288999301125-127.0.0.1:35056_qzk%2Fov-n_00,
 state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.]
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded




Build Log:
[...truncated 11480 lines...]
   [junit4] Suite: org.apache.solr.cloud.CdcrVersionReplicationTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-core/test/J1/temp/solr.cloud.CdcrVersionReplicationTest_C9CAF9AA37E1B10E-001/init-core-data-001
   [junit4]   2> 1733148 INFO  
(SUITE-CdcrVersionReplicationTest-seed#[C9CAF9AA37E1B10E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 1733149 INFO  
(SUITE-CdcrVersionReplicationTest-seed#[C9CAF9AA37E1B10E]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /qzk/ov
   [junit4]   2> 1733168 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1733176 INFO  (Thread-4162) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1733176 INFO  (Thread-4162) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1733367 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.ZkTestServer start zk server on port:51081
   [junit4]   2> 1733417 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/solrconfig-cdcr.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1733421 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1733423 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 1733436 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 1733438 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 1733450 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/currency.xml
 to /configs/conf1/currency.xml
   [junit4]   2> 1733451 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/enumsConfig.xml
 to /configs/conf1/enumsConfig.xml
   [junit4]   2> 1733453 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/open-exchange-rates.json
 to /configs/conf1/open-exchange-rates.json
   [junit4]   2> 1733454 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[C9CAF9AA37E1B10E]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/test-files/solr/collection1/conf/mapping-ISOLatin1Accent.txt
 to /configs/conf1/mapping-ISOLatin1Accent.txt
   [junit4]   2> 1733460 INFO  

[jira] [Created] (SOLR-9575) Initialize an empty solr-home

[David Smiley (JIRA)]

David Smiley created SOLR-9575:
--

 Summary: Initialize an empty solr-home
 Key: SOLR-9575
 URL: https://issues.apache.org/jira/browse/SOLR-9575
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley


The user may not want to use Solr's default solr-home dir location -- most 
likely to use a separate disk.  If you do this, there are two main problems:
* solr.xml & zoo.cfg aren't there
* configsets aren't there

Of course you could copy it manually but that's an extra step, and it's 
particularly annoying to add this step to a Docker setup.  Docker is all the 
rage these days, and for good reason.  If I mount a volume at 
/opt/solr/server/solr then it basically masks this part of the built-in Solr 
image (thus making configsets completely invisible) and points to some place 
that will be empty.  Solr obviously complains.  I could set the solr-home to 
some other path that I mount, but Solr would still complain about an empty 
solr-home -- no solr.xml

If solr-home is empty, and if it's a dir other than the default solr-home, then 
I think the solr-home should be initialized with solr.xml and zoo.cfg copied 
from the default solr-home.  I think configsets should be referenced from the 
default solr-home if there is no configsets dir in solr-home.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9572) config API to show expanded useParams for request handlers inline

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9572:
-
Summary: config API to show expanded useParams for request handlers inline  
(was: config API to show the parameters used for request handlers inline)

> config API to show expanded useParams for request handlers inline
> -
>
> Key: SOLR-9572
> URL: https://issues.apache.org/jira/browse/SOLR-9572
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9572.patch, SOLR-9572.patch
>
>
> sample request
> {{http://localhost:8983/solr/gettingstarted/config/requestHandler?expandParams=true=/browse}}
> The new parameter is expandParams and it expands all the params and will show 
> all the params expanded individually and cumulative
> response:
> {code:JavaScript}
> {
>"config":{"requestHandler":{"/browse":{
> "name":"/browse",
> "class":"solr.SearchHandler",
> "useParams":"query,facets,velocity,browse",
> "defaults":{"echoParams":"explicit"},
> "_useParamsExpanded_":{
>   "query":{
> "defType":"edismax",
> "q.alt":"*:*",
> "rows":"10",
> "fl":"*,score",
> "":{"v":0}},
>   "facets":{
> "facet":"on",
> "facet.mincount":"1",
> "":{"v":0}},
>   "velocity":{
> "wt":"velocity",
> "v.template":"browse",
> "v.layout":"layout",
> "":{"v":0}},
>   "browse":"[NOT AVAILABLE]"},
> "_effectiveParams_":{
>   "q.alt":"*:*",
>   "indent":"true",
>   "echoParams":"explicit",
>   "v.layout":"layout",
>   "fl":"*,score",
>   "rows":"10",
>   "v.template":"browse",
>   "defType":"edismax",
>   "facet.mincount":"1",
>   "wt":"json",
>   "facet":"on"}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9411) Better validation of dynamic field for Schema API

[JIRA]

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

Jan Høydahl commented on SOLR-9411:
---

Good catch. Feel free to piggy-back on this issue and adjust title and CHANGES 
entry accordingly.

> Better validation of dynamic field for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411-part2.patch, SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9572) config API to show the parameters used for request handlers inline

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9572:
-
Attachment: SOLR-9572.patch

tests added

> config API to show the parameters used for request handlers inline
> --
>
> Key: SOLR-9572
> URL: https://issues.apache.org/jira/browse/SOLR-9572
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9572.patch, SOLR-9572.patch
>
>
> sample request
> {{http://localhost:8983/solr/gettingstarted/config/requestHandler?expandParams=true=/browse}}
> The new parameter is expandParams and it expands all the params and will show 
> all the params expanded individually and cumulative
> response:
> {code:JavaScript}
> {
>"config":{"requestHandler":{"/browse":{
> "name":"/browse",
> "class":"solr.SearchHandler",
> "useParams":"query,facets,velocity,browse",
> "defaults":{"echoParams":"explicit"},
> "_useParamsExpanded_":{
>   "query":{
> "defType":"edismax",
> "q.alt":"*:*",
> "rows":"10",
> "fl":"*,score",
> "":{"v":0}},
>   "facets":{
> "facet":"on",
> "facet.mincount":"1",
> "":{"v":0}},
>   "velocity":{
> "wt":"velocity",
> "v.template":"browse",
> "v.layout":"layout",
> "":{"v":0}},
>   "browse":"[NOT AVAILABLE]"},
> "_effectiveParams_":{
>   "q.alt":"*:*",
>   "indent":"true",
>   "echoParams":"explicit",
>   "v.layout":"layout",
>   "fl":"*,score",
>   "rows":"10",
>   "v.template":"browse",
>   "defType":"edismax",
>   "facet.mincount":"1",
>   "wt":"json",
>   "facet":"on"}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6677) Reduce logging during startup and shutdown

[JIRA]

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

Jan Høydahl commented on SOLR-6677:
---

Here is what I see on one of the nodes when starting a 3-node cloud setup with 
the current master:
{noformat}
INFO  - 2016-09-27 20:44:46.881; [   ] org.apache.solr.cloud.ZkController; 
Register node as live in ZooKeeper:/live_nodes/192.168.0.11:8983_solr
INFO  - 2016-09-27 20:44:46.886; [   ] 
org.apache.solr.common.cloud.ZkStateReader; Updated live nodes from 
ZooKeeper... (0) -> (1)
...
INFO  - 2016-09-27 20:44:51.654; [   ] 
org.apache.solr.common.cloud.ZkStateReader; Updated live nodes from 
ZooKeeper... (1) -> (2)
INFO  - 2016-09-27 20:44:57.451; [   ] 
org.apache.solr.common.cloud.ZkStateReader; Updated live nodes from 
ZooKeeper... (2) -> (3)
...
INFO  - 2016-09-27 20:45:46.723; [   ] 
org.apache.solr.common.cloud.ZkStateReader$StateWatcher; A cluster state 
change: [WatchedEvent state:SyncConnected type:NodeDataChanged 
path:/collections/gettingstarted/state.json] for collection [gettingstarted] 
has occurred - updating... (live nodes size: [3])
{noformat}

I think this is sufficient.

> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>  Components: logging
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

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

Jan Høydahl commented on SOLR-9570:
---

The file {{solr-8983-console.log}} is simply a redirect of all stdout/err from 
the start script. It is only written when in backgoround mode, and log4j's 
ConsoleAppender is always muted when the file is written. The file is useful 
since it will capture any errors happening outside of the logging system such 
as System.out.println or stdout/stderr printouts from some of Solr's 
dependencies etc. So we should never redirect stdout/err to {{/dev/null}}. I 
think we should try to do some simple rotation not to lose potential important 
info after a crash.

The main log will append, and when we switch to Log4j2 we can implement startup 
rotation.

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-6058:


Surely we can close this now?  I see there are sub-tasks, some of which were 
not gotten too (turned out to be lower priority I suppose)... Can we still 
close this any way?

> Solr needs a new website
> 
>
> Key: SOLR-6058
> URL: https://issues.apache.org/jira/browse/SOLR-6058
> Project: Solr
>  Issue Type: Task
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
> Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
> SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
> Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
> Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf
>
>
> Solr needs a new website:  better organization of content, less verbose, more 
> pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9411) Better validation of dynamic field for Schema API

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9411:
-
Attachment: SOLR-9411-part2.patch

+1 to your changes [~janhoy].

This add-on patch:

* Switches the "add-field" operation to use IndexSchema.newField() instead of 
SchemaField.create(), to take advantage of the more extensive validation there.
* Adds a test to TestBulkSchemaAPI that attempts to add invalid fields using 
"add-field".
* Removes the fieldtype existence check from the "add-field" and 
"add-dynamic-field" operations, since IndexSchema.new(Dynamic)Field() already 
handles this validation.

Running tests now.

> Better validation of dynamic field for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411-part2.patch, SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-9572) config API to show the parameters used for request handlers inline

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-9572:


Assignee: Noble Paul

> config API to show the parameters used for request handlers inline
> --
>
> Key: SOLR-9572
> URL: https://issues.apache.org/jira/browse/SOLR-9572
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9572.patch
>
>
> sample request
> {{http://localhost:8983/solr/gettingstarted/config/requestHandler?expandParams=true=/browse}}
> The new parameter is expandParams and it expands all the params and will show 
> all the params expanded individually and cumulative
> response:
> {code:JavaScript}
> {
>"config":{"requestHandler":{"/browse":{
> "name":"/browse",
> "class":"solr.SearchHandler",
> "useParams":"query,facets,velocity,browse",
> "defaults":{"echoParams":"explicit"},
> "_useParamsExpanded_":{
>   "query":{
> "defType":"edismax",
> "q.alt":"*:*",
> "rows":"10",
> "fl":"*,score",
> "":{"v":0}},
>   "facets":{
> "facet":"on",
> "facet.mincount":"1",
> "":{"v":0}},
>   "velocity":{
> "wt":"velocity",
> "v.template":"browse",
> "v.layout":"layout",
> "":{"v":0}},
>   "browse":"[NOT AVAILABLE]"},
> "_effectiveParams_":{
>   "q.alt":"*:*",
>   "indent":"true",
>   "echoParams":"explicit",
>   "v.layout":"layout",
>   "fl":"*,score",
>   "rows":"10",
>   "v.template":"browse",
>   "defType":"edismax",
>   "facet.mincount":"1",
>   "wt":"json",
>   "facet":"on"}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9572) config API to show the parameters used for request handlers inline

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9572:
-
Attachment: SOLR-9572.patch

without testcase

> config API to show the parameters used for request handlers inline
> --
>
> Key: SOLR-9572
> URL: https://issues.apache.org/jira/browse/SOLR-9572
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
> Attachments: SOLR-9572.patch
>
>
> sample request
> {{http://localhost:8983/solr/gettingstarted/config/requestHandler?expandParams=true=/browse}}
> The new parameter is expandParams and it expands all the params and will show 
> all the params expanded individually and cumulative
> response:
> {code:JavaScript}
> {
>"config":{"requestHandler":{"/browse":{
> "name":"/browse",
> "class":"solr.SearchHandler",
> "useParams":"query,facets,velocity,browse",
> "defaults":{"echoParams":"explicit"},
> "_useParamsExpanded_":{
>   "query":{
> "defType":"edismax",
> "q.alt":"*:*",
> "rows":"10",
> "fl":"*,score",
> "":{"v":0}},
>   "facets":{
> "facet":"on",
> "facet.mincount":"1",
> "":{"v":0}},
>   "velocity":{
> "wt":"velocity",
> "v.template":"browse",
> "v.layout":"layout",
> "":{"v":0}},
>   "browse":"[NOT AVAILABLE]"},
> "_effectiveParams_":{
>   "q.alt":"*:*",
>   "indent":"true",
>   "echoParams":"explicit",
>   "v.layout":"layout",
>   "fl":"*,score",
>   "rows":"10",
>   "v.template":"browse",
>   "defType":"edismax",
>   "facet.mincount":"1",
>   "wt":"json",
>   "facet":"on"}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9572) config API to show the parameters used for request handlers inline

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9572:
-
Description: 
sample request
{{http://localhost:8983/solr/gettingstarted/config/requestHandler?expandParams=true=/browse}}

The new parameter is expandParams and it expands all the params and will show 
all the params expanded individually and cumulative

response:
{code:JavaScript}
{
   "config":{"requestHandler":{"/browse":{
"name":"/browse",
"class":"solr.SearchHandler",
"useParams":"query,facets,velocity,browse",
"defaults":{"echoParams":"explicit"},
"_useParamsExpanded_":{
  "query":{
"defType":"edismax",
"q.alt":"*:*",
"rows":"10",
"fl":"*,score",
"":{"v":0}},
  "facets":{
"facet":"on",
"facet.mincount":"1",
"":{"v":0}},
  "velocity":{
"wt":"velocity",
"v.template":"browse",
"v.layout":"layout",
"":{"v":0}},
  "browse":"[NOT AVAILABLE]"},
"_effectiveParams_":{
  "q.alt":"*:*",
  "indent":"true",
  "echoParams":"explicit",
  "v.layout":"layout",
  "fl":"*,score",
  "rows":"10",
  "v.template":"browse",
  "defType":"edismax",
  "facet.mincount":"1",
  "wt":"json",
  "facet":"on"}
{code}

> config API to show the parameters used for request handlers inline
> --
>
> Key: SOLR-9572
> URL: https://issues.apache.org/jira/browse/SOLR-9572
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>
> sample request
> {{http://localhost:8983/solr/gettingstarted/config/requestHandler?expandParams=true=/browse}}
> The new parameter is expandParams and it expands all the params and will show 
> all the params expanded individually and cumulative
> response:
> {code:JavaScript}
> {
>"config":{"requestHandler":{"/browse":{
> "name":"/browse",
> "class":"solr.SearchHandler",
> "useParams":"query,facets,velocity,browse",
> "defaults":{"echoParams":"explicit"},
> "_useParamsExpanded_":{
>   "query":{
> "defType":"edismax",
> "q.alt":"*:*",
> "rows":"10",
> "fl":"*,score",
> "":{"v":0}},
>   "facets":{
> "facet":"on",
> "facet.mincount":"1",
> "":{"v":0}},
>   "velocity":{
> "wt":"velocity",
> "v.template":"browse",
> "v.layout":"layout",
> "":{"v":0}},
>   "browse":"[NOT AVAILABLE]"},
> "_effectiveParams_":{
>   "q.alt":"*:*",
>   "indent":"true",
>   "echoParams":"explicit",
>   "v.layout":"layout",
>   "fl":"*,score",
>   "rows":"10",
>   "v.template":"browse",
>   "defType":"edismax",
>   "facet.mincount":"1",
>   "wt":"json",
>   "facet":"on"}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (SOLR-9410) make ReRankQParserPlugin's private ReRankWeight public

[Christine Poerschke (JIRA)]

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

Christine Poerschke closed SOLR-9410.
-
   Resolution: Fixed
Fix Version/s: 6.2
   master (7.0)

> make ReRankQParserPlugin's private ReRankWeight public
> --
>
> Key: SOLR-9410
> URL: https://issues.apache.org/jira/browse/SOLR-9410
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (7.0), 6.2
>
> Attachments: SOLR-9410-ReRankWeight.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/ReRankQParserPlugin.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9410) make ReRankQParserPlugin's private ReRankWeight public

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-9410:
--
Summary: make ReRankQParserPlugin's private ReRankWeight public  (was: make 
ReRankQParserPlugin's private ReRankWeight public and ReRankQuery part abstract)

> make ReRankQParserPlugin's private ReRankWeight public
> --
>
> Key: SOLR-9410
> URL: https://issues.apache.org/jira/browse/SOLR-9410
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9410-ReRankWeight.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/ReRankQParserPlugin.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9410) make ReRankQParserPlugin's private ReRankWeight public and ReRankQuery part abstract

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-9410:
---

ReRankQuery part moved to SOLR-9574 to avoid one JIRA ticket spanning two solr 
releases.

> make ReRankQParserPlugin's private ReRankWeight public and ReRankQuery part 
> abstract
> 
>
> Key: SOLR-9410
> URL: https://issues.apache.org/jira/browse/SOLR-9410
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9410-ReRankWeight.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/ReRankQParserPlugin.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9574) factor out AbstractReRankQuery class

[Christine Poerschke (JIRA)]

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

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

Attaching proposed patch. In this code snippet here
{code}
public Query rewrite(IndexReader reader) throws IOException {
  Query q = mainQuery.rewrite(reader);
  if (q != mainQuery) {
return rewrite(q);
  }
  return super.rewrite(reader);
}

protected abstract Query rewrite(Query rewrittenMainQuery) throws IOException;
...
protected Query rewrite(Query rewrittenMainQuery) throws IOException {
  return new ReRankQuery(reRankQuery, reRankDocs, 
reRankWeight).wrap(rewrittenMainQuery);
}
{code}
i could see the abstract method being called something else (what though?) but 
the wrap call i think should definitely go in the abstract method since 
something like
{code}
protected Query rewrite(Query rewrittenMainQuery) throws IOException {
  return new MyReRankQuery(rewrittenMainQuery, reRankQuery, reRankDocs, 
reRankWeight);
}
{code}
would be a valid implementation.

> factor out AbstractReRankQuery class
> 
>
> Key: SOLR-9574
> URL: https://issues.apache.org/jira/browse/SOLR-9574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9574.patch
>
>
> Motivation is to avoid unnecessary code duplication between 
> ReRankQParserPlugin and the SOLR-8542 plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9574) factor out AbstractReRankQuery class

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-9574:
-

 Summary: factor out AbstractReRankQuery class
 Key: SOLR-9574
 URL: https://issues.apache.org/jira/browse/SOLR-9574
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor


Motivation is to avoid unnecessary code duplication between ReRankQParserPlugin 
and the SOLR-8542 plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: LUCENE_CHANGES.txt???

[Jan Høydahl]

> LUCENE_CHANGES.txt should be in the binary and source release tarballs/zips - 
> see SOLR-6342.

Ah, my bad, I did not notice that file before, so the reference is OK then :)
Regarding release date, I always use CHANGES.txt, not Changes.html
Also the HTML has the problem of not knowing the date of the current release 
btw, see http://lucene.apache.org/solr/6_2_1/changes/Changes.html 


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

> 27. sep. 2016 kl. 17.02 skrev Steve Rowe :
> 
> LUCENE_CHANGES.txt should be in the binary and source release tarballs/zips - 
> see SOLR-6342.
> 
> The problem of all of the mentions linking to the same online HTML is known: 
> SOLR-6384.  I should fix that :).
> 
> --
> Steve
> www.lucidworks.com
> 
>> On Sep 27, 2016, at 10:01 AM, Alexandre Rafalovitch  
>> wrote:
>> 
>> The HTML file generated links to the Lucene's version of the changes
>> HTML file. Unfortunately, ALL of the mentions link to the same
>> top-level point of that file, so are somewhat redundant.
>> 
>> Also, the HTML version fills-in the exact release dates by extracting
>> them from JIRA's API.
>> 
>> So, when we say "fix", what do we mean exactly?
>> 
>> Regards,
>>  Alex.
>> 
>> Newsletter and resources for Solr beginners and intermediates:
>> http://www.solr-start.com/
>> 
>> 
>> On 27 September 2016 at 20:10, Jan Høydahl  wrote:
>>> What if we for the version being released say “Release date: September 2016
>>> (current release, see exact date on release archive)”
>>> but when we create the section heading for the next release we also fill in
>>> the exact date for the previous one.
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 27. sep. 2016 kl. 15.03 skrev Yonik Seeley :
>>> 
>>> Release dates were always a problem because one would have to guess
>>> when the vote would pass (and change the date every time a new RC is
>>> spun... error prone).  Perhaps just add month+year?
>>> 
>>> -Yonik
>>> 
>>> 
>>> On Tue, Sep 27, 2016 at 8:53 AM, David Smiley 
>>> wrote:
>>> 
>>> +1 to fix the reference to Lucene's CHANGES.txt and to add release dates.
>>> 
>>> On Tue, Sep 27, 2016 at 8:36 AM Jan Høydahl  wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> In Solr’s CHANGES.txt there is this line for every release since 4.10:
>>> 
>>> Consult the LUCENE_CHANGES.txt file for additional, low level, changes
>>> in this release.
>>> 
>>> But there is no file with that name…
>>> 
>>> 
>>> Also, why don’t we add the release date for each release also to
>>> CHANGES.txt?
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 
>>> -
>>> 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
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Commented] (SOLR-6677) Reduce logging during startup and shutdown

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-6677:


bq. Do you see a need to log it even if there is no change?

At SolrCloud startup, it might be nice to have one log entry with the number of 
nodes ... if we are able to detect when the number has become stable.  Then 
after that, only log this at INFO if the number changes.  I can't say whether 
it makes sense to log at DEBUG or TRACE when the node number stays the same.

> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>  Components: logging
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Deleting multiple comments from Confluence

[Jan Høydahl]

Good point. No use cleaning something that will soon be gone.
As I understand we’ll set up redirects from most old live RefGuide URLs.
Will the Solr project then stop using Confluence, or shall we re-purpose
it for something else, e.g. create a new space for community WIKI
instead of MoinMoin?

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

> 27. sep. 2016 kl. 16.56 skrev Cassandra Targett :
> 
> Bulk comment delete is not a native Confluence feature, so that
> functionality is coming from a plugin. Click the "i" button on the
> license error screen, and you go to a 3rd party vendor website.
> 
> The error means the license for the plugin (it's $$ for commercial
> users) has expired. You'll need to talk to INFRA to see if it can be
> renewed. Usually open source projects get free plugin licenses, but
> that's up to the vendor. It might be a quick process to renew it, or
> something more complicated.
> 
> However, I'm doubtful of the overall value of systematically cleaning
> up "off-topic" comments as a project in itself. While they are noise,
> they aren't getting migrated to the new system. Your time is your
> prerogative, as always, and I definitely appreciate in general your
> attention to the Ref Guide and your help resolving these comments. My
> point is only your help would also be welcome with getting us off
> Confluence.
> 
> On Tue, Sep 27, 2016 at 3:32 AM, Jan Høydahl  wrote:
>> I’m very much logged in, I can edit pages and delete single comments without
>> problem, but entering the “Delete multiple comments with checkboxes” mode
>> which I was able to use before is now out of reach :(
>> Does it work for you?
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>> 27. sep. 2016 kl. 10.27 skrev Alexandre Rafalovitch :
>> 
>> Make sure you are logged in. Not just think you are logged in. There is
>> funny caching there.
>> 
>> At least that could be one cause that I run into.
>> 
>> Regards,
>>Alex
>> 
>> 
>> On 27 Sep 2016 2:42 PM, "Jan Høydahl"  wrote:
>>> 
>>> Seems I don’t have permissions to delete multiple comments from a
>>> Confluence page anymore.
>>> I click the link “Delete comments” on a comment (e.g
>>> https://cwiki.apache.org/confluence/plugins/aptis/deleteAllComments/ask-user.action?pageId=32604161)
>>> and is shown an error msg "No valid License”. This used to work before,
>>> and is time saving when cleaning up old cruft.
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9570:


I think we could avoid creating a console logfile at all in most conditions, 
and not worry about rotating it at all.  Here's what I think should happen with 
the console logging:

 * background, console NOT muted: redirect to console log.
 * background, console muted:  redirect to /dev/null.
 * foreground: don't mute.  Output to console, do not redirect or copy to 
console log.

I don't know whether the first condition would ever actually happen, but if it 
can happen, we could have console log rotation *only* in that situation, 
rotating the console log through a fixed and limited set of filenames where the 
oldest one is simply deleted.

The main log is rotated by log4j, but the script currently renames the active 
log on startup, so that a fresh log is always from server start.  If a 
predictable string of text is logged *only* at service start and can be found 
with a backwards search from the end of the file, we might not need to have the 
script rename solr.log at startup.  If log4j can do startup rotation, that 
would take care of the issue entirely.

I'll take your word on the GC log.  I haven't looked into it.

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8975) SolrClient setters should be deprecated in favor of SolrClientBuilder methods

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-8975:
---

As an additional question/comment, the attached patch takes the values formerly 
provided to various setters, and adds them as parameters to the current 
"kitchen-sink" ctor (the one with all params used by the Builder).  This is 
technically a breaking change, as the ctor now has more arguments than it did 
previously.  Maybe this isn't a huge deal, as these "kitchen-sink" ctors have 
already been deprecated.

But I suspect what I should do is change the patch to create _new_ deprecated 
kitchen-sink ctors that incorporate all the setter params, and leave the 
current (no longer "kitchen-sink") ctors as-is.

Just wanted to confirm that.  If no one suggests otherwise, I'll make that 
change shortly.

> SolrClient setters should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-8975
> URL: https://issues.apache.org/jira/browse/SOLR-8975
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-8975.patch
>
>
> SOLR-8097 added a builder layer on top of each {{SolrClient}} implementation.
> Now that builders are in place for SolrClients, the setters used in each 
> SolrClient can be deprecated, and their functionality moved over to the 
> Builders.  This change brings a few benefits:
> - unifies SolrClient configuration under the new Builders.  It'll be nice to 
> have all the knobs, and levers used to tweak SolrClients available in a 
> single place (the Builders).
> - reduces SolrClient thread-safety concerns.  Currently, clients are mutable. 
>  Using some SolrClient setters can result in erratic and "trappy" behavior 
> when the clients are used across multiple threads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9166) Export handler returns zero for numeric fields that are not in the original doc

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-9166:
-
Assignee: Rohit  (was: Erick Erickson)

> Export handler returns zero for numeric fields that are not in the original 
> doc
> ---
>
> Key: SOLR-9166
> URL: https://issues.apache.org/jira/browse/SOLR-9166
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Rohit
> Attachments: SOLR-9166.patch
>
>
> From the dev list discussion:
> My original post.
> Zero is different from not
> existing. And let's claim that I want to process a stream and, say,
> facet on in integer field over the result set. There's no way on the
> client side to distinguish between a document that has a zero in the
> field and one that didn't have the field in the first place so I'll
> over-count the zero bucket.
> From Dennis Gove:
> Is this true for non-numeric fields as well? I agree that this seems like a 
> very bad thing.
> I can't imagine that a fix would cause a problem with Streaming Expressions, 
> ParallelSQL, or other given that the /select handler is not returning 0 for 
> these missing fields (the /select handler is the default handler for the 
> Streaming API so if nulls were a problem I imagine we'd have already seen 
> it). 
> That said, within Streaming Expressions there is a select(...) function which 
> supports a replace(...) operation which allows you to replace one value (or 
> null) with some other value. If a 0 were necessary one could use a 
> select(...) to replace null with 0 using an expression like this 
>select(, replace(fieldA, null, withValue=0)). 
> The end result of that would be that the field fieldA would never have a null 
> value and for all tuples where a null value existed it would be replaced with 
> 0.
> Details on the select function can be found at 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61330338#StreamingExpressions-select.
> And to answer Denis' question, null gets returned for string DocValues fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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_102) - Build # 17914 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17914/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

18 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

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

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


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

Error Message:
Captured an uncaught exception in thread: Thread[id=4824, name=RMI 
RenewClean-[127.0.0.1:35112], state=RUNNABLE, group=system]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4824, name=RMI RenewClean-[127.0.0.1:35112], 
state=RUNNABLE, group=system]
Caused by: java.lang.OutOfMemoryError: Java heap space
at 
sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:593)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
Captured an uncaught exception in thread: Thread[id=16166, 
name=qtp18308286-16166, state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=16166, name=qtp18308286-16166, state=RUNNABLE, 
group=TGRP-CdcrVersionReplicationTest]
Caused by: java.lang.OutOfMemoryError: Java heap space


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

Error Message:
Captured an uncaught exception in thread: Thread[id=16132, 
name=qtp26303499-16132, state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=16132, name=qtp26303499-16132, state=RUNNABLE, 
group=TGRP-CdcrVersionReplicationTest]
Caused by: java.lang.OutOfMemoryError: Java heap space


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

Error Message:
Captured an uncaught exception in thread: Thread[id=11503, 
name=qtp2285062-11503, state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=11503, name=qtp2285062-11503, state=RUNNABLE, 
group=TGRP-CdcrVersionReplicationTest]
Caused by: java.lang.OutOfMemoryError: Java heap space


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

Error Message:
Captured an uncaught exception in thread: Thread[id=11604, 
name=org.eclipse.jetty.server.session.HashSessionManager@198a318Timer, 
state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=11604, 
name=org.eclipse.jetty.server.session.HashSessionManager@198a318Timer, 
state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]
Caused by: java.lang.OutOfMemoryError: Java heap space


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

Error Message:
Captured an uncaught exception in thread: Thread[id=11595, 
name=Scheduler-16944924, state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=11595, name=Scheduler-16944924, state=RUNNABLE, 
group=TGRP-CdcrVersionReplicationTest]
Caused by: java.lang.OutOfMemoryError: Java heap space


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

Error Message:
Captured an uncaught exception in thread: Thread[id=11509, 
name=org.eclipse.jetty.server.session.HashSessionManager@6602e4Timer, 
state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=11509, 
name=org.eclipse.jetty.server.session.HashSessionManager@6602e4Timer, 
state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]
Caused by: java.lang.OutOfMemoryError: Java heap space


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

Error Message:
Captured an uncaught exception in thread: Thread[id=11541, 
name=org.eclipse.jetty.server.session.HashSessionManager@18bf919Timer, 
state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=11541, 
name=org.eclipse.jetty.server.session.HashSessionManager@18bf919Timer, 
state=RUNNABLE, group=TGRP-CdcrVersionReplicationTest]
Caused by: java.lang.OutOfMemoryError: Java heap space


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

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

[Policeman Jenkins Server]

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

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

Error Message:


Stack Trace:
org.apache.solr.common.cloud.ZooKeeperException: 
at 
__randomizedtesting.SeedInfo.seed([5091E14C089238EA:A807EAEEFAF4D7F6]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:564)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForCollectionToDisappear(BaseCdcrDistributedZkTest.java:494)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.startServers(BaseCdcrDistributedZkTest.java:596)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.createSourceCollection(BaseCdcrDistributedZkTest.java:346)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.baseBefore(BaseCdcrDistributedZkTest.java:168)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:905)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-9441) Solr collection backup on HDFS can only be manipulated by the Solr process owner

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9441:


[~varunthacker] Did you get a chance to review the patch?

> Solr collection backup on HDFS can only be manipulated by the Solr process 
> owner
> 
>
> Key: SOLR-9441
> URL: https://issues.apache.org/jira/browse/SOLR-9441
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: trunk
>Reporter: Hrishikesh Gadre
>
> When we backup Solr collection using HDFS backup repository, the backup 
> folder (and the files) are created with permissions 755 (i.e. only solr 
> process owner can delete/move the backup folder). This is inconvenient from 
> user perspective since the backup is essentially a full-copy of the Solr 
> collection and hence manipulating it doesn't affect the Solr collection state 
> in any way.
> We should provide an option by which we can enable other users to manipulate 
> the backup folders. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9570:


I like the idea of keeping with Log4j's options rather than manual/hand-rolled 
file juggling.  Can we tell Log4j, at some very early of point of startup (like 
before we've logged anything) to rotate the log?  That'd be nice.  I wonder if 
Log4j2 or Logback support such a configuration option -- it seems like 
something very desirable.  If we don't find such an option, I'm fine with Jan's 
recommendation of just accepting that the logs since boot aren't necessarily at 
the top.

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 1895 lines...]
   [junit4] Suite: org.apache.lucene.search.TestFuzzyQuery
   [junit4]   2> 9월 25, 2016 4:08:54 오전 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.search.TestFuzzyQuery
   [junit4]   2>1) Thread[id=2972, 
name=SUITE-TestFuzzyQuery-seed#[AEF39117F58BD628], state=RUNNABLE, 
group=TGRP-TestFuzzyQuery]
   [junit4]   2> at java.lang.Thread.getStackTrace(Thread.java:1556)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:688)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:685)
   [junit4]   2> at java.security.AccessController.doPrivileged(Native 
Method)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.getStackTrace(ThreadLeakControl.java:685)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.getThreadsWithTraces(ThreadLeakControl.java:701)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.formatThreadStacksFull(ThreadLeakControl.java:681)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.access$1000(ThreadLeakControl.java:64)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:414)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:681)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:140)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:591)
   [junit4]   2>2) Thread[id=1, name=main, state=WAITING, group=main]
   [junit4]   2> at java.lang.Object.wait(Native Method)
   [junit4]   2> at java.lang.Thread.join(Thread.java:1249)
   [junit4]   2> at java.lang.Thread.join(Thread.java:1323)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:601)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:450)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:243)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:354)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:10)
   [junit4]   2>3) Thread[id=9, name=JUnit4-serializer-daemon, 
state=TIMED_WAITING, group=main]
   [junit4]   2> at java.lang.Thread.sleep(Native Method)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.events.Serializer$1.run(Serializer.java:47)
   [junit4]   2>4) Thread[id=2973, 
name=TEST-TestFuzzyQuery.testRandom-seed#[AEF39117F58BD628], state=RUNNABLE, 
group=TGRP-TestFuzzyQuery]
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedContext.context(RandomizedContext.java:254)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedContext.current(RandomizedContext.java:151)
   [junit4]   2> at 
org.apache.lucene.util.LuceneTestCase.random(LuceneTestCase.java:730)
   [junit4]   2> at 
org.apache.lucene.search.TestFuzzyQuery.randomSimpleString(TestFuzzyQuery.java:506)
   [junit4]   2> at 
org.apache.lucene.search.TestFuzzyQuery.testRandom(TestFuzzyQuery.java:517)
   [junit4]   2> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
   [junit4]   2> at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]   2> at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]   2> at java.lang.reflect.Method.invoke(Method.java:498)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
   [junit4]   2> at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
   [junit4]   2> at 

[jira] [Commented] (SOLR-2820) Add both model and state to ZooKeeper layout for SolrCloud

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-2820:
-

It feels like this is really out of date? If not, can we get an updated 
description of what's needed in modern SolrCloud?

> Add both model and state to ZooKeeper layout for SolrCloud
> --
>
> Key: SOLR-2820
> URL: https://issues.apache.org/jira/browse/SOLR-2820
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Mark Miller
>
> Current we skimp by here by having the model and simple node state - we 
> really want the model and full cluster state longer term though.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7438:
--

BTW I reviewed the W.E.H. and posted a comparison: 
https://github.com/wikimedia/search-highlighter/issues/19

> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
> Attachments: LUCENE_7438_UH_benchmark.patch
>
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7456) PerField(DocValues|Postings)Format do not call the per-field merge methods

[Julien MASSENET (JIRA)]

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

Julien MASSENET commented on LUCENE-7456:
-

I agree that being this sneaky is not ideal, but the only alternative I see 
would be change the Postings API.

In this patch, I tried to keep modifications constrained to the 
{{org.apache.lucene.codecs.perfield}} package, but I can give a shot at trying 
to a come up with a cleaner implementation that updates the other APIs if you 
want.

I've uploaded an updated version of the patch which does not remove the 
sneakiness but makes the {{PerFieldMergeState}} more robust:
* The {{FilterFieldInfos}} class now correctly computes and exposes the 
{{hasXXX}} properties.
* Calls to {{FilterFieldInfos.fieldInfo()}} and 
{{FilterFieldsProducer.terms()}} now throw {{IllegalArgumentException}} if 
called with fields outside if the current merge context
* I've tweaked the unit tests to work with the latest 6.2.1 since the 
{{Legacy*}} field types are not accessible in this module anymore.

As for why we're overriding merge() calls in our codec:
* We're using a customized codec to emulate nested documents.
* It works with the same idea as BlockJoin, but is less generic (it's tailored 
to our use case).
* The main difference is that the maxDoc() for segments remain equal to the 
number of "parent" documents, with only the nested fields having larger posting 
lists.
* For it to work, when merging, we need to rebase correctly the "docIds" for 
the nested documents (using the same idea as the docMap in the general use 
case).

> PerField(DocValues|Postings)Format do not call the per-field merge methods
> --
>
> Key: LUCENE-7456
> URL: https://issues.apache.org/jira/browse/LUCENE-7456
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 6.2.1
>Reporter: Julien MASSENET
> Attachments: LUCENE-7456-v2.patch, LUCENE-7456.patch
>
>
> While porting some old codec code from Lucene 4.3.1, I couldn't get the 
> per-field formats to call upon the per-field merge methods; the default merge 
> method was always being called.
> I think this is a side-effect of LUCENE-5894.
> Attached is a patch with a test that reproduces the error and an associated 
> fix that pass the unit tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7456) PerField(DocValues|Postings)Format do not call the per-field merge methods

[Julien MASSENET (JIRA)]

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

Julien MASSENET updated LUCENE-7456:

Attachment: LUCENE-7456-v2.patch

> PerField(DocValues|Postings)Format do not call the per-field merge methods
> --
>
> Key: LUCENE-7456
> URL: https://issues.apache.org/jira/browse/LUCENE-7456
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 6.2.1
>Reporter: Julien MASSENET
> Attachments: LUCENE-7456-v2.patch, LUCENE-7456.patch
>
>
> While porting some old codec code from Lucene 4.3.1, I couldn't get the 
> per-field formats to call upon the per-field merge methods; the default merge 
> method was always being called.
> I think this is a side-effect of LUCENE-5894.
> Attached is a patch with a test that reproduces the error and an associated 
> fix that pass the unit tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: LUCENE_CHANGES.txt???

[Steve Rowe]

LUCENE_CHANGES.txt should be in the binary and source release tarballs/zips - 
see SOLR-6342.

The problem of all of the mentions linking to the same online HTML is known: 
SOLR-6384.  I should fix that :).

--
Steve
www.lucidworks.com

> On Sep 27, 2016, at 10:01 AM, Alexandre Rafalovitch  
> wrote:
> 
> The HTML file generated links to the Lucene's version of the changes
> HTML file. Unfortunately, ALL of the mentions link to the same
> top-level point of that file, so are somewhat redundant.
> 
> Also, the HTML version fills-in the exact release dates by extracting
> them from JIRA's API.
> 
> So, when we say "fix", what do we mean exactly?
> 
> Regards,
>   Alex.
> 
> Newsletter and resources for Solr beginners and intermediates:
> http://www.solr-start.com/
> 
> 
> On 27 September 2016 at 20:10, Jan Høydahl  wrote:
>> What if we for the version being released say “Release date: September 2016
>> (current release, see exact date on release archive)”
>> but when we create the section heading for the next release we also fill in
>> the exact date for the previous one.
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>> 27. sep. 2016 kl. 15.03 skrev Yonik Seeley :
>> 
>> Release dates were always a problem because one would have to guess
>> when the vote would pass (and change the date every time a new RC is
>> spun... error prone).  Perhaps just add month+year?
>> 
>> -Yonik
>> 
>> 
>> On Tue, Sep 27, 2016 at 8:53 AM, David Smiley 
>> wrote:
>> 
>> +1 to fix the reference to Lucene's CHANGES.txt and to add release dates.
>> 
>> On Tue, Sep 27, 2016 at 8:36 AM Jan Høydahl  wrote:
>> 
>> 
>> Hi,
>> 
>> In Solr’s CHANGES.txt there is this line for every release since 4.10:
>> 
>>  Consult the LUCENE_CHANGES.txt file for additional, low level, changes
>> in this release.
>> 
>> But there is no file with that name…
>> 
>> 
>> Also, why don’t we add the release date for each release also to
>> CHANGES.txt?
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>> 
>> -
>> 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
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Deleting multiple comments from Confluence

[Cassandra Targett]

Bulk comment delete is not a native Confluence feature, so that
functionality is coming from a plugin. Click the "i" button on the
license error screen, and you go to a 3rd party vendor website.

The error means the license for the plugin (it's $$ for commercial
users) has expired. You'll need to talk to INFRA to see if it can be
renewed. Usually open source projects get free plugin licenses, but
that's up to the vendor. It might be a quick process to renew it, or
something more complicated.

However, I'm doubtful of the overall value of systematically cleaning
up "off-topic" comments as a project in itself. While they are noise,
they aren't getting migrated to the new system. Your time is your
prerogative, as always, and I definitely appreciate in general your
attention to the Ref Guide and your help resolving these comments. My
point is only your help would also be welcome with getting us off
Confluence.

On Tue, Sep 27, 2016 at 3:32 AM, Jan Høydahl  wrote:
> I’m very much logged in, I can edit pages and delete single comments without
> problem, but entering the “Delete multiple comments with checkboxes” mode
> which I was able to use before is now out of reach :(
> Does it work for you?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 27. sep. 2016 kl. 10.27 skrev Alexandre Rafalovitch :
>
> Make sure you are logged in. Not just think you are logged in. There is
> funny caching there.
>
> At least that could be one cause that I run into.
>
> Regards,
> Alex
>
>
> On 27 Sep 2016 2:42 PM, "Jan Høydahl"  wrote:
>>
>> Seems I don’t have permissions to delete multiple comments from a
>> Confluence page anymore.
>> I click the link “Delete comments” on a comment (e.g
>> https://cwiki.apache.org/confluence/plugins/aptis/deleteAllComments/ask-user.action?pageId=32604161)
>> and is shown an error msg "No valid License”. This used to work before,
>> and is time saving when cleaning up old cruft.
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[jira] [Resolved] (LUCENE-6231) smokeTestRelease.py should retry failed downloads

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-6231.

Resolution: Won't Fix

We use svn.apache.org instead of people.apache.org now, and AFAIK failed 
downloads are no longer an issue.

> smokeTestRelease.py should retry failed downloads
> -
>
> Key: LUCENE-6231
> URL: https://issues.apache.org/jira/browse/LUCENE-6231
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.0, 5.2
>
> Attachments: LUCENE-6231-lucene_solr_4_10.patch, 
> LUCENE-6231-lucene_solr_4_10.patch, LUCENE-6231-part-2.patch, 
> LUCENE-6231-part-3.patch, LUCENE-6231-part-3.patch, LUCENE-6231-part-3.patch, 
> LUCENE-6231.patch
>
>
> In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
> the smoke tester against the people.apache.org RC URL all failed because of 
> download failures.
> I had the same problem - my first two attempts also failed because of failed 
> downloads - here's the trace from one of them:
> {noformat}
> Traceback (most recent call last):
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py",
>  line 1248, in do_open
> h.request(req.get_method(), req.selector, req.data, headers)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py",
>  line 1061, in request
> self._send_request(method, url, body, headers)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py",
>  line 1099, in _send_request
> self.endheaders(body)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py",
>  line 1057, in endheaders
> self._send_output(message_body)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py",
>  line 902, in _send_output
> self.send(msg)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py",
>  line 840, in send
> self.connect()
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py",
>  line 818, in connect
> self.timeout, self.source_address)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py",
>  line 435, in create_connection
> raise err
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py",
>  line 426, in create_connection
> sock.connect(sa)
> TimeoutError: [Errno 60] Operation timed out
> During handling of the above exception, another exception occurred:
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 117, in download
> fIn = urllib.request.urlopen(urlString)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py",
>  line 156, in urlopen
> return opener.open(url, data, timeout)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py",
>  line 469, in open
> response = self._open(req, data)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py",
>  line 487, in _open
> '_open', req)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py",
>  line 447, in _call_chain
> result = func(*args)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py",
>  line 1268, in http_open
> return self.do_open(http.client.HTTPConnection, req)
>   File 
> "/Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py",
>  line 1251, in do_open
> raise URLError(err)
> urllib.error.URLError: 
> The above exception was the direct cause of the following exception:
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1523, in 
> main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1468, in main
> smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
> '.join(c.test_args))
>   File "dev-tools/scripts/smokeTestRelease.py", line 1517, in smokeTest
> checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
>   File 

Re: Deleting multiple comments from Confluence

[Alexandre Rafalovitch]

Ok,

It does not work for me either (anymore?). Sorry for the noise.

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 27 September 2016 at 15:32, Jan Høydahl  wrote:
> I’m very much logged in, I can edit pages and delete single comments without
> problem, but entering the “Delete multiple comments with checkboxes” mode
> which I was able to use before is now out of reach :(
> Does it work for you?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 27. sep. 2016 kl. 10.27 skrev Alexandre Rafalovitch :
>
> Make sure you are logged in. Not just think you are logged in. There is
> funny caching there.
>
> At least that could be one cause that I run into.
>
> Regards,
> Alex
>
>
> On 27 Sep 2016 2:42 PM, "Jan Høydahl"  wrote:
>>
>> Seems I don’t have permissions to delete multiple comments from a
>> Confluence page anymore.
>> I click the link “Delete comments” on a comment (e.g
>> https://cwiki.apache.org/confluence/plugins/aptis/deleteAllComments/ask-user.action?pageId=32604161)
>> and is shown an error msg "No valid License”. This used to work before,
>> and is time saving when cleaning up old cruft.
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[jira] [Created] (SOLR-9573) Parameter debugQuery=true is behaving incorrectly for the normal two phase distributed search

[Markus Jelsma (JIRA)]

Markus Jelsma created SOLR-9573:
---

 Summary: Parameter debugQuery=true is behaving incorrectly for the 
normal two phase distributed search
 Key: SOLR-9573
 URL: https://issues.apache.org/jira/browse/SOLR-9573
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.1
Reporter: Markus Jelsma
 Fix For: master (7.0)


Parameter debugQuery=true is behaving incorrectly for the normal two phase 
distributed search.

See: 
http://search-lucene.com/m/eHNlU7sATlbFEK=Results+not+ordered+by+score+and+debug+info+is+incorrect+crazy



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9567) factor out ReRankCollector from ReRankQParserPlugin

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-9567.
---
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.x

> factor out ReRankCollector from ReRankQParserPlugin
> ---
>
> Key: SOLR-9567
> URL: https://issues.apache.org/jira/browse/SOLR-9567
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.x, master (7.0)
>
> Attachments: SOLR-9567.patch, SOLR-9567.patch
>
>
> Factor out the collector used by ReRankQParserPlugin so that similar 
> reranking queries (e.g. SOLR-8542) can use the same collector.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_102) - Build # 1815 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1815/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [NRTCachingDirectory] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:372)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:254) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:397) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$handleRequestBody$0(ReplicationHandler.java:279)
  at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [NRTCachingDirectory]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:372)
at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:254)
at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:397)
at 
org.apache.solr.handler.ReplicationHandler.lambda$handleRequestBody$0(ReplicationHandler.java:279)
at java.lang.Thread.run(Thread.java:745)


at __randomizedtesting.SeedInfo.seed([2726B794D2D1E2C6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:261)
at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11556 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_2726B794D2D1E2C6-001/init-core-data-001
   [junit4]   2> 978610 INFO  
(SUITE-TestReplicationHandler-seed#[2726B794D2D1E2C6]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=None)
   [junit4]   2> 978611 INFO  

Re: LUCENE_CHANGES.txt???

[Alexandre Rafalovitch]

The HTML file generated links to the Lucene's version of the changes
HTML file. Unfortunately, ALL of the mentions link to the same
top-level point of that file, so are somewhat redundant.

Also, the HTML version fills-in the exact release dates by extracting
them from JIRA's API.

So, when we say "fix", what do we mean exactly?

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 27 September 2016 at 20:10, Jan Høydahl  wrote:
> What if we for the version being released say “Release date: September 2016
> (current release, see exact date on release archive)”
> but when we create the section heading for the next release we also fill in
> the exact date for the previous one.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 27. sep. 2016 kl. 15.03 skrev Yonik Seeley :
>
> Release dates were always a problem because one would have to guess
> when the vote would pass (and change the date every time a new RC is
> spun... error prone).  Perhaps just add month+year?
>
> -Yonik
>
>
> On Tue, Sep 27, 2016 at 8:53 AM, David Smiley 
> wrote:
>
> +1 to fix the reference to Lucene's CHANGES.txt and to add release dates.
>
> On Tue, Sep 27, 2016 at 8:36 AM Jan Høydahl  wrote:
>
>
> Hi,
>
> In Solr’s CHANGES.txt there is this line for every release since 4.10:
>
>   Consult the LUCENE_CHANGES.txt file for additional, low level, changes
> in this release.
>
> But there is no file with that name…
>
>
> Also, why don’t we add the release date for each release also to
> CHANGES.txt?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> 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
>
>
> -
> 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] [Updated] (SOLR-9140) Replace some state polling with CollectionStateWatchers

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-9140:

Attachment: SOLR-9140.patch

Bringing this patch up to date.  The teething problems with 
CollectionStateWatchers have all been ironed out, so I think this can be added 
back without causing any problems.

This changes knocks a couple of seconds off collection creation, which should 
speed up some of our tests.

> Replace some state polling with CollectionStateWatchers
> ---
>
> Key: SOLR-9140
> URL: https://issues.apache.org/jira/browse/SOLR-9140
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9140.patch, SOLR-9140.patch, SOLR-9140.patch
>
>
> There are a few places in ZkController and the collection processing code 
> that directly query ZK for collection state, and then wait and poll for 
> expected state changes.  We can now replace these with 
> CollectionStateWatchers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

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

Jan Høydahl commented on SOLR-9570:
---

Actually my plan is as follows:
For the main solr.log I propose to stop moving the old log before startup, and 
instead rely on log4j's default of continuing to append the existing file. 
Although it is nice with a new file on each startup, I don't think it is a 
must? This single change will fix the issue. You can just search for "Welcome 
to Apache Solr" to find each new startup.

Wrt the solr_gc.log I'm also going to enable log rotation, which is supported 
since JRE7. But the gc log rotation works differently, it will first write to 
{{solr_gc.log.0.current}} until size limit and then rename it to 
{{solr_gc.log.0}} and start writing {{solr_gc.log.1.current}} etc. On every 
restart it unfortunately always starts overwriting {{solr_gc.log.0.current}}. 
One option could be to on startup create {{$SOLR_LOGS_DIR/old/}} (or wipe it if 
exists) and move all current gc logs there.

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9570) Logs backed up on restart are kept forever

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9570:


If old logs are moved into a subdirectory, then the shell script can use the 
"find" utility to clean them up.  This utility exists on most POSIX systems and 
although there are differences in capability between different systems, I think 
there is strong effort to accept the options for core usage like this on all 
platforms.

It's possible to do something similar in Windows, but in typical style, it 
requires a syntax change depending on the Windows version.

> Logs backed up on restart are kept forever
> --
>
> Key: SOLR-9570
> URL: https://issues.apache.org/jira/browse/SOLR-9570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>
> When (re)starting Solr, the start script will backup any existing 
> {{solr.log}} or {{solr_gc.log}} to a file {{solr_log_}} and 
> {{solr_gc_log_}} respectively. That may be all good, but these old 
> copies are never cleaned up, as they are not under the control of log4j.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: LUCENE_CHANGES.txt???

[Jan Høydahl]

What if we for the version being released say “Release date: September 2016 
(current release, see exact date on release archive)”
but when we create the section heading for the next release we also fill in the 
exact date for the previous one.

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

> 27. sep. 2016 kl. 15.03 skrev Yonik Seeley :
> 
> Release dates were always a problem because one would have to guess
> when the vote would pass (and change the date every time a new RC is
> spun... error prone).  Perhaps just add month+year?
> 
> -Yonik
> 
> 
> On Tue, Sep 27, 2016 at 8:53 AM, David Smiley  
> wrote:
>> +1 to fix the reference to Lucene's CHANGES.txt and to add release dates.
>> 
>> On Tue, Sep 27, 2016 at 8:36 AM Jan Høydahl  wrote:
>>> 
>>> Hi,
>>> 
>>> In Solr’s CHANGES.txt there is this line for every release since 4.10:
>>> 
>>>   Consult the LUCENE_CHANGES.txt file for additional, low level, changes
>>> in this release.
>>> 
>>> But there is no file with that name…
>>> 
>>> 
>>> Also, why don’t we add the release date for each release also to
>>> CHANGES.txt?
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
>>> 
>>> -
>>> 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
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: LUCENE_CHANGES.txt???

[Yonik Seeley]

Release dates were always a problem because one would have to guess
when the vote would pass (and change the date every time a new RC is
spun... error prone).  Perhaps just add month+year?

-Yonik


On Tue, Sep 27, 2016 at 8:53 AM, David Smiley  wrote:
> +1 to fix the reference to Lucene's CHANGES.txt and to add release dates.
>
> On Tue, Sep 27, 2016 at 8:36 AM Jan Høydahl  wrote:
>>
>> Hi,
>>
>> In Solr’s CHANGES.txt there is this line for every release since 4.10:
>>
>>Consult the LUCENE_CHANGES.txt file for additional, low level, changes
>> in this release.
>>
>> But there is no file with that name…
>>
>>
>> Also, why don’t we add the release date for each release also to
>> CHANGES.txt?
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>>
>> -
>> 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

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

[jira] [Commented] (SOLR-9567) factor out ReRankCollector from ReRankQParserPlugin

[ASF subversion and git services (JIRA)]

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

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

Commit d195f7ad0e9f635673a519ba7c48a191e501a723 in lucene-solr's branch 
refs/heads/branch_6x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d195f7a ]

SOLR-9567: Make ReRankQParserPlugin's private ReRankCollector a public class of 
its own. (Christine Poerschke)


> factor out ReRankCollector from ReRankQParserPlugin
> ---
>
> Key: SOLR-9567
> URL: https://issues.apache.org/jira/browse/SOLR-9567
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9567.patch, SOLR-9567.patch
>
>
> Factor out the collector used by ReRankQParserPlugin so that similar 
> reranking queries (e.g. SOLR-8542) can use the same collector.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: LUCENE_CHANGES.txt???

[David Smiley]

+1 to fix the reference to Lucene's CHANGES.txt and to add release dates.

On Tue, Sep 27, 2016 at 8:36 AM Jan Høydahl  wrote:

> Hi,
>
> In Solr’s CHANGES.txt there is this line for every release since 4.10:
>
>Consult the LUCENE_CHANGES.txt file for additional, low level, changes
> in this release.
>
> But there is no file with that name…
>
>
> Also, why don’t we add the release date for each release also to
> CHANGES.txt?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> 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

LUCENE_CHANGES.txt???

[Jan Høydahl]

Hi,

In Solr’s CHANGES.txt there is this line for every release since 4.10:

   Consult the LUCENE_CHANGES.txt file for additional, low level, changes in 
this release.

But there is no file with that name…


Also, why don’t we add the release date for each release also to CHANGES.txt?

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


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

[jira] [Commented] (SOLR-9567) factor out ReRankCollector from ReRankQParserPlugin

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9567: Make ReRankQParserPlugin's private ReRankCollector a public class of 
its own. (Christine Poerschke)


> factor out ReRankCollector from ReRankQParserPlugin
> ---
>
> Key: SOLR-9567
> URL: https://issues.apache.org/jira/browse/SOLR-9567
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9567.patch, SOLR-9567.patch
>
>
> Factor out the collector used by ReRankQParserPlugin so that similar 
> reranking queries (e.g. SOLR-8542) can use the same collector.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6677) Reduce logging during startup and shutdown

[JIRA]

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

Jan Høydahl updated SOLR-6677:
--
Component/s: logging

> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>  Components: logging
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9411) Better validation of dynamic field for Schema API

[JIRA]

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

Jan Høydahl resolved SOLR-9411.
---
Resolution: Fixed

> Better validation of dynamic field for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6677) Reduce logging during startup and shutdown

[JIRA]

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

Jan Høydahl updated SOLR-6677:
--
Fix Version/s: master (7.0)
   6.3

> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-9325) solr.log written to {solrRoot}/server/logs instead of location specified by SOLR_LOGS_DIR

[JIRA]

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

Jan Høydahl reassigned SOLR-9325:
-

Assignee: Jan Høydahl

> solr.log written to {solrRoot}/server/logs instead of location specified by 
> SOLR_LOGS_DIR
> -
>
> Key: SOLR-9325
> URL: https://issues.apache.org/jira/browse/SOLR-9325
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.0.1
> Environment: 64-bit CentOS 7 with latest patches, JVM 1.8.0.92
>Reporter: Tim Parker
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9325.patch
>
>
> (6.1 is probably also affected, but we've been blocked by SOLR-9231)
> solr.log should be written to the directory specified by the SOLR_LOGS_DIR 
> environment variable, but instead it's written to {solrRoot}/server/logs.
> This results in requiring that solr is installed on a writable device, which 
> leads to two problems:
> 1) solr installation can't live on a shared device (single copy shared by two 
> or more VMs)
> 2) solr installation is more difficult to lock down
> Solr should be able to run without error in this test scenario:
> burn the Solr directory tree onto a CD-ROM
> Mount this CD as /solr
> run Solr from there (with appropriate environment variables set, of course)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9325) solr.log written to {solrRoot}/server/logs instead of location specified by SOLR_LOGS_DIR

[JIRA]

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

Jan Høydahl updated SOLR-9325:
--
Fix Version/s: master (7.0)
   6.3

> solr.log written to {solrRoot}/server/logs instead of location specified by 
> SOLR_LOGS_DIR
> -
>
> Key: SOLR-9325
> URL: https://issues.apache.org/jira/browse/SOLR-9325
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.0.1
> Environment: 64-bit CentOS 7 with latest patches, JVM 1.8.0.92
>Reporter: Tim Parker
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9325.patch
>
>
> (6.1 is probably also affected, but we've been blocked by SOLR-9231)
> solr.log should be written to the directory specified by the SOLR_LOGS_DIR 
> environment variable, but instead it's written to {solrRoot}/server/logs.
> This results in requiring that solr is installed on a writable device, which 
> leads to two problems:
> 1) solr installation can't live on a shared device (single copy shared by two 
> or more VMs)
> 2) solr installation is more difficult to lock down
> Solr should be able to run without error in this test scenario:
> burn the Solr directory tree onto a CD-ROM
> Mount this CD as /solr
> run Solr from there (with appropriate environment variables set, of course)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9325) solr.log written to {solrRoot}/server/logs instead of location specified by SOLR_LOGS_DIR

[JIRA]

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

Jan Høydahl updated SOLR-9325:
--
Attachment: SOLR-9325.patch

First patch. Sets {{-Dsolr.log.dir=$SOLR_LOGS_DIR}} in start script and uses 
variable $\{solr.log.dir\} in log4j.properties. Default still set to relative 
"logs".

NOT tested at all on Windows (anyone?), tested some on macOS

> solr.log written to {solrRoot}/server/logs instead of location specified by 
> SOLR_LOGS_DIR
> -
>
> Key: SOLR-9325
> URL: https://issues.apache.org/jira/browse/SOLR-9325
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.0.1
> Environment: 64-bit CentOS 7 with latest patches, JVM 1.8.0.92
>Reporter: Tim Parker
> Attachments: SOLR-9325.patch
>
>
> (6.1 is probably also affected, but we've been blocked by SOLR-9231)
> solr.log should be written to the directory specified by the SOLR_LOGS_DIR 
> environment variable, but instead it's written to {solrRoot}/server/logs.
> This results in requiring that solr is installed on a writable device, which 
> leads to two problems:
> 1) solr installation can't live on a shared device (single copy shared by two 
> or more VMs)
> 2) solr installation is more difficult to lock down
> Solr should be able to run without error in this test scenario:
> burn the Solr directory tree onto a CD-ROM
> Mount this CD as /solr
> run Solr from there (with appropriate environment variables set, of course)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([5254636972522C97:3AEB5643A2C83E7B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:137)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:282)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Created] (SOLR-9572) config API to show the parameters used for request handlers inline

[Noble Paul (JIRA)]

Noble Paul created SOLR-9572:


 Summary: config API to show the parameters used for request 
handlers inline
 Key: SOLR-9572
 URL: https://issues.apache.org/jira/browse/SOLR-9572
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9569) Moving to a unified solrconfig experience

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9569:
-
Description: 
* Any config API call will result in a collection reload. We should ensure that 
only the relevant component is reloaded. This will work only for components 
specified in the configoverlay.json
* Move most commonly used paths to ImplicitPlugins
* move their request parameters to params.json
* Enhance the config API to expand show the params used for each requesthandler 
inline



Today we use the solrconfig.xml as a place to document things. As we move more 
stuff off of solrconfig.xml let's point it to a ref guide page to discuss about 
all the requesthandlers available by default and their configuration

  was:
* Move most commonly used paths to ImplicitPlugins
* move their request parameters to params.json
** To make this easier to understand enhance the solconfig API to expand show 
the params used for each requesthandler inline
* Remove {{path}} usage in {{initParams}}

Today we use the solrconfig.xml as a place to document things. As we move more 
stuff off of solrconfig.xml let's point it to a ref guide page to discuss about 
all the requesthandlers available by default and their configuration


> Moving to a unified solrconfig experience
> -
>
> Key: SOLR-9569
> URL: https://issues.apache.org/jira/browse/SOLR-9569
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> * Any config API call will result in a collection reload. We should ensure 
> that only the relevant component is reloaded. This will work only for 
> components specified in the configoverlay.json
> * Move most commonly used paths to ImplicitPlugins
> * move their request parameters to params.json
> * Enhance the config API to expand show the params used for each 
> requesthandler inline
> Today we use the solrconfig.xml as a place to document things. As we move 
> more stuff off of solrconfig.xml let's point it to a ref guide page to 
> discuss about all the requesthandlers available by default and their 
> configuration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9569) Moving to a unified solrconfig experience

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9569:
-
Summary: Moving to a unified solrconfig experience  (was: Cleanup sample 
configuration with best practices)

> Moving to a unified solrconfig experience
> -
>
> Key: SOLR-9569
> URL: https://issues.apache.org/jira/browse/SOLR-9569
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> * Move most commonly used paths to ImplicitPlugins
> * move their request parameters to params.json
> ** To make this easier to understand enhance the solconfig API to expand show 
> the params used for each requesthandler inline
> * Remove {{path}} usage in {{initParams}}
> Today we use the solrconfig.xml as a place to document things. As we move 
> more stuff off of solrconfig.xml let's point it to a ref guide page to 
> discuss about all the requesthandlers available by default and their 
> configuration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9325) solr.log written to {solrRoot}/server/logs instead of location specified by SOLR_LOGS_DIR

[JIRA]

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

Jan Høydahl commented on SOLR-9325:
---

Tested this on master now.
Changing {{SOLR_LOGS_DIR}} in solr.in.sh will cause console and gc logs to go 
to the new dir, but not {{solr.log}} which is hardcoded in {{log4j.properties}}.

However, this is clearly documented in solr.in.sh, so user is told how to fix 
it. Still I think we should try to somehow propagate the env.var into the log4j 
file

> solr.log written to {solrRoot}/server/logs instead of location specified by 
> SOLR_LOGS_DIR
> -
>
> Key: SOLR-9325
> URL: https://issues.apache.org/jira/browse/SOLR-9325
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.0.1
> Environment: 64-bit CentOS 7 with latest patches, JVM 1.8.0.92
>Reporter: Tim Parker
>
> (6.1 is probably also affected, but we've been blocked by SOLR-9231)
> solr.log should be written to the directory specified by the SOLR_LOGS_DIR 
> environment variable, but instead it's written to {solrRoot}/server/logs.
> This results in requiring that solr is installed on a writable device, which 
> leads to two problems:
> 1) solr installation can't live on a shared device (single copy shared by two 
> or more VMs)
> 2) solr installation is more difficult to lock down
> Solr should be able to run without error in this test scenario:
> burn the Solr directory tree onto a CD-ROM
> Mount this CD as /solr
> run Solr from there (with appropriate environment variables set, of course)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (SOLR-4450) Developer Curb Appeal: Need consistent command line arguments for all nodes

[JIRA]

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

Jan Høydahl closed SOLR-4450.
-
Resolution: Not A Problem

Closing this old issue. This is really not a problem any more now that we have 
{{solr start -e cloud}} for testing, and the clear recommendation to use 
external ZK for other setups (which gives you equal setup on all nodes).

> Developer Curb Appeal: Need consistent command line arguments for all nodes
> ---
>
> Key: SOLR-4450
> URL: https://issues.apache.org/jira/browse/SOLR-4450
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.1
>Reporter: Mark Bennett
> Fix For: 6.0, 4.9
>
>
> Suppose you want to create a small 4 node cluster (2x2, two shards, each 
> replicated), each on it's own machine.
> It'd be nice to use the same script in /etc/init.d to start them all, but 
> it's hard to come up with a set of arguments that works for both the first 
> and subsequent nodes.
> When MANUALLY starting them, the arguments for the first node are different 
> than for subsequent nodes:
> Node A like this:
> -DzkRun -DnumShards=2 -Dbootstrap_confdir=./solr/collection1/conf 
> -Dcollection.configName=MyConfig -jar start.jar
> Vs. the other 3 nodes, B, C, D:
>   -DzkHost=nodeA:9983 -jar start.jar
> But if you combine them, you either still have to rely on Node A being up 
> first, and have all nodes reference it:
> -DzkRun -DzkHost=nodeA:9983 -DnumShards=2 
> -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=MyConfig
> OR you can try to specify the address of all 4 machines, in all 4 startup 
> scripts, which seems logical but doesn't work:
> -DzkRun -DzkHost=nodeA:9983,nodeB:9983,nodeC:9983,nodeD:9983 
> -DnumShards=2 -Dbootstrap_confdir=./solr/collection1/conf 
> -Dcollection.configName=MyConfig
> This gives an error:
> org.apache.solr.common.SolrException log
> SEVERE: null:java.lang.IllegalArgumentException: port out of range:-1
> This thread suggests a possible change in syntax, but doesn't seem to work 
> (at least with the embedded ZooKeeper)
> Thread:
> http://lucene.472066.n3.nabble.com/solr4-0-problem-zkHost-with-multiple-hosts-throws-out-of-range-exception-td4014440.html
> Syntax:
> -DzkRun -DzkHost=nodeA:9983,nodeB:9983,nodeC:9983,nodeD:9983/solrroot 
> -DnumShards=2 -Dbootstrap_confdir=./solr/collection1/conf 
> -Dcollection.configName=MyConfig
> Error:
> SEVERE: Could not start Solr. Check solr/home property and the logs
> Feb 12, 2013 1:36:49 PM org.apache.solr.common.SolrException log
> SEVERE: null:java.lang.NumberFormatException: For input string: 
> "9983/solrroot"
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> So:
> * There needs to be some syntax that all nodes can run, even if it requires 
> listing addresses  (or multicast!)
> * And then clear documentation about suggesting external ZooKeeper to be used 
> for production (list being maintained in SOLR-)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8232) bin/solr does not rotate console log file

[JIRA]

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

Jan Høydahl resolved SOLR-8232.
---
Resolution: Not A Problem

Now that we mute CONSOLE appenders when running in bg, the console log file 
becomes almost empty, so the risk of it filling up during a run is now almost 
nonexistent. On each restart a new file is started, and in SOLR-9570 I propose 
to delete the oldest of those.

I'm resolving this as "Not a problem" for now. If you believe that stdout/err 
logging during a single run still should rotate its log file automatically 
(which requires something else than redirect) then please re-open and continue 
work on this issue.

> bin/solr does not rotate console log file
> -
>
> Key: SOLR-8232
> URL: https://issues.apache.org/jira/browse/SOLR-8232
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.3
>Reporter: Upayavira
>Priority: Minor
>
> The bin/solr script, when started with bin/solr start, uses this command to 
> start Solr:
> {code} nohup "$JAVA" "${SOLR_START_OPTS[@]}" $SOLR_ADDL_ARGS -jar start.jar \
> "-XX:OnOutOfMemoryError=$SOLR_TIP/bin/oom_solr.sh $SOLR_PORT 
> $SOLR_LOGS_DIR" "${SOLR_JETTY_CONFIG[@]}" \
> 1>"$SOLR_LOGS_DIR/solr-$SOLR_PORT-console.log" 2>&1 & echo $! > 
> "$SOLR_PID_DIR/solr-$SOLR_PORT.pid"
> {code}
> This sends console output to stdout, with no means of rotating the log file, 
> meaning it will eventually fill the drive unless restarted.
> I would propose that stdout be written to dev/null and we use proper means 
> for handling logging, which can do proper log rotation as configured by the 
> user.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6677) Reduce logging during startup and shutdown

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-6677: More log noise reduction


> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6677) Reduce logging during startup and shutdown

[ASF subversion and git services (JIRA)]

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

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

Commit 1d46b419df356d0142732bd0745ccd1ab0606704 in lucene-solr's branch 
refs/heads/branch_6x from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1d46b41 ]

SOLR-6677: More log noise reduction


> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9571) Time-allowed detection logic in LBHttpSolrClient should return a fake partial results response

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-9571:
---

 Summary: Time-allowed detection logic in LBHttpSolrClient should 
return a fake partial results response
 Key: SOLR-9571
 URL: https://issues.apache.org/jira/browse/SOLR-9571
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Alan Woodward


See https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/435/

LBHttpSolrClient checks before each forward attempt that it hasn't already 
overstepped the time allowed for the request.  On expiry, it ought to return a 
fake response containing a 'partial response' header, as if the timeout had 
been hit on a responding Solr node; at the moment, it just throws a 'no live 
servers available' exception, which is misleading.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6677) Reduce logging during startup and shutdown

[JIRA]

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

Jan Høydahl commented on SOLR-6677:
---

[~romseygeek], please add your name to the SOLR-6677 CHANGES.txt entry on your 
next commit :-)

> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6677) Reduce logging during startup and shutdown

[JIRA]

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

Jan Høydahl commented on SOLR-6677:
---

Pushed part 3

> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6677) Reduce logging during startup and shutdown

[ASF subversion and git services (JIRA)]

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

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

Commit 1ac2b0159492243250a2ef95ec29feeec9baf510 in lucene-solr's branch 
refs/heads/branch_6x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1ac2b01 ]

SOLR-6677: part 3, moving some more to DEBUG. Only printing "Updated live nodes 
from ZooKeeper..." if there was actually a change

(cherry picked from commit 0eaa85f)


> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6677) Reduce logging during startup and shutdown

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-6677: part 3, moving some more to DEBUG. Only printing "Updated live nodes 
from ZooKeeper..." if there was actually a change


> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9411) Better validation of dynamic field for Schema API

[ASF subversion and git services (JIRA)]

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

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

Commit 53fcc7563c1010e34a8f0889968711816bcb89ff in lucene-solr's branch 
refs/heads/branch_6x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=53fcc75 ]

SOLR-9411: Better validation of dynamic field for Schema API

(cherry picked from commit 8046fe2)


> Better validation of dynamic field for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6677) Reduce logging during startup and shutdown

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-6677:

Attachment: SOLR-6677-part-4.patch

+1 to the ZK logging changes.

Here's some more, mostly around config and schema loading:
* lots of INFO->DEBUG
* summarised a few useful schema INFO log lines into a single line
* moved a couple of INFO lines about deprecated schema entities to WARN
* conversely, moved a couple of DirectoryFactory WARN lines to DEBUG (creating 
a new index directory and not finding any old directories to clean up - both 
entirely normal!)

> Reduce logging during startup and shutdown
> --
>
> Key: SOLR-6677
> URL: https://issues.apache.org/jira/browse/SOLR-6677
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Jan Høydahl
> Attachments: SOLR-6677-part-2.patch, SOLR-6677-part-4.patch, 
> SOLR-6677-part3.patch, SOLR-6677.patch, SOLR-6677.patch
>
>
> most of what is printed is neither helpful nor useful. It's just noise



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9411) Better validation of dynamic field for Schema API

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9411: Better validation of dynamic field for Schema API


> Better validation of dynamic field for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

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

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

Error Message:
No live SolrServers available to handle this request

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request
at 
__randomizedtesting.SeedInfo.seed([D0A9AEEB905F5BCA:58FD91313EA33632]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:382)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1280)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.assertPartialResults(CloudExitableDirectoryReaderTest.java:106)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTimeoutTests(CloudExitableDirectoryReaderTest.java:78)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test(CloudExitableDirectoryReaderTest.java:56)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Updated] (SOLR-9411) Better validation of dynamic field for Schema API

[JIRA]

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

Jan Høydahl updated SOLR-9411:
--
Summary: Better validation of dynamic field for Schema API  (was: Better 
validation for Schema API)

> Better validation of dynamic field for Schema API
> -
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9411) Better validation for Schema API

[JIRA]

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

Jan Høydahl updated SOLR-9411:
--
Attachment: SOLR-9411.patch

Updated patch.

Fixes {{SchemaTest}} which attempted to create dynamic fields with 
required=true and defaultValue. This succeeded earlier due to this same bug

> Better validation for Schema API
> 
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411.patch, SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9554) Multiple ManagedIndexSchemaFactory upgrades running simultaneously can clash, causing cores not to load

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-9554:

Attachment: SOLR-9554.patch

Sure, here it is.

> Multiple ManagedIndexSchemaFactory upgrades running simultaneously can clash, 
> causing cores not to load
> ---
>
> Key: SOLR-9554
> URL: https://issues.apache.org/jira/browse/SOLR-9554
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9554.patch
>
>
> If a collection is created using a configset with a ManagedSchemaFactory but 
> no managed-schema file, then multiple cores may try and convert the schema 
> file simultaneously.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9570) Logs backed up on restart are kept forever

[JIRA]

Jan Høydahl created SOLR-9570:
-

 Summary: Logs backed up on restart are kept forever
 Key: SOLR-9570
 URL: https://issues.apache.org/jira/browse/SOLR-9570
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Reporter: Jan Høydahl


When (re)starting Solr, the start script will backup any existing {{solr.log}} 
or {{solr_gc.log}} to a file {{solr_log_}} and {{solr_gc_log_}} 
respectively. That may be all good, but these old copies are never cleaned up, 
as they are not under the control of log4j.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9554) Multiple ManagedIndexSchemaFactory upgrades running simultaneously can clash, causing cores not to load

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9554:


Can you attach this test? 

> Multiple ManagedIndexSchemaFactory upgrades running simultaneously can clash, 
> causing cores not to load
> ---
>
> Key: SOLR-9554
> URL: https://issues.apache.org/jira/browse/SOLR-9554
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>
> If a collection is created using a configset with a ManagedSchemaFactory but 
> no managed-schema file, then multiple cores may try and convert the schema 
> file simultaneously.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Deleting multiple comments from Confluence

[Jan Høydahl]

I’m very much logged in, I can edit pages and delete single comments without 
problem, but entering the “Delete multiple comments with checkboxes” mode which 
I was able to use before is now out of reach :(
Does it work for you?

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

> 27. sep. 2016 kl. 10.27 skrev Alexandre Rafalovitch :
> 
> Make sure you are logged in. Not just think you are logged in. There is funny 
> caching there.
> 
> At least that could be one cause that I run into.
> 
> Regards,
> Alex
> 
> 
> On 27 Sep 2016 2:42 PM, "Jan Høydahl"  > wrote:
> Seems I don’t have permissions to delete multiple comments from a Confluence 
> page anymore.
> I click the link “Delete comments” on a comment (e.g 
> https://cwiki.apache.org/confluence/plugins/aptis/deleteAllComments/ask-user.action?pageId=32604161
>  
> )
> and is shown an error msg "No valid License”. This used to work before, and 
> is time saving when cleaning up old cruft.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 

Re: Deleting multiple comments from Confluence

[Alexandre Rafalovitch]

Make sure you are logged in. Not just think you are logged in. There is
funny caching there.

At least that could be one cause that I run into.

Regards,
Alex

On 27 Sep 2016 2:42 PM, "Jan Høydahl"  wrote:

> Seems I don’t have permissions to delete multiple comments from a
> Confluence page anymore.
> I click the link “Delete comments” on a comment (e.g
> https://cwiki.apache.org/confluence/plugins/aptis/
> deleteAllComments/ask-user.action?pageId=32604161)
> and is shown an error msg "No valid License”. This used to work before,
> and is time saving when cleaning up old cruft.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-9554) Multiple ManagedIndexSchemaFactory upgrades running simultaneously can clash, causing cores not to load

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-9554:
-

Another failure caused by this: 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/869/consoleFull

In this case, the race is as follows:
* core 1 finds that there's no managed-schema
* core 2 finds that there's no managed-schema
* core 1 loads schema.xml, upgrades to managed-schema, and moves schema.xml to 
schema.xml.bak
* core 2 tries to load schema.xml and crashes with a NullPointerException

I've tried writing a test case to hammer on this, but it refuses to fail - 
possibly it needs to be running on a slow enough machine?  In any case, I think 
we need some kind of distributed lock when doing the fallback-and-upgrade 
manoeuvre.

> Multiple ManagedIndexSchemaFactory upgrades running simultaneously can clash, 
> causing cores not to load
> ---
>
> Key: SOLR-9554
> URL: https://issues.apache.org/jira/browse/SOLR-9554
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>
> If a collection is created using a configset with a ManagedSchemaFactory but 
> no managed-schema file, then multiple cores may try and convert the schema 
> file simultaneously.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (SOLR-9564) Unable to connect to SOLR CLOUD NODES

[JIRA]

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

Jan Høydahl closed SOLR-9564.
-
Resolution: Invalid

This is not a support tracker for questions about production issues.

It may be a "blocker" for your business, but we urge you to contact the party 
responsible for providing support and operations for your Solr instance. If you 
do not have any such contract with anyone, you are free to use the channels the 
Apache Solr™ open source project provides. You will find links here: 
http://lucene.apache.org/solr/resources.html#community The main channel is to 
subscribe to and send an email to the solr-u...@lucene.apache.org mailing list.

I will now close this JIRA, as this bug tracker is for software bugs only.

> Unable to connect to SOLR CLOUD NODES
> -
>
> Key: SOLR-9564
> URL: https://issues.apache.org/jira/browse/SOLR-9564
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Pahuni Saharan
>Priority: Blocker
> Fix For: 5.2.1
>
>
> We have two solr cloud nodes setup on the Zookeeper.
> SOLR version is 5.2.1 and Zookeeper Version is 3.4.6.
> SOLR CLOUD Architecture has Listing which is connected to shards which in 
> turn is connected to 2 SOLR CLOUD NODES.
> Our Production API which brings listing from SOLR nodes became 
> unavailable.SOLR nodes logs were not generated  and did not log any activity 
> for 6 hours when Production was unavailable.SOLR files got rotated with the 
> timestamp when we restarted SOLR service and Zookeeper.out showed below 
> errors in log at the start of downtime:
> EndOfStreamException: Unable to read additional data from client sessionid 
> 0x156a6ca33180002, likely client has closed socket 
> 2016-09-26 04:25:07,545 [myid:1] - WARN  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@357] - caught end of 
> stream exception
> EndOfStreamException: Unable to read additional data from client sessionid 
> 0x156a6ca33180002, likely client has closed socket
> at 
> org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
> at 
> org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
> at java.lang.Thread.run(Thread.java:745)
> ZOO.CFG has below settings:
> [Replaced IP's Intentionally with x's for security purpose]
> server.1=172.x.x.x:2888:3888
> server.2=172.x.x.x:2888:3888
> server.3=172.x.x.x:2888:3888
> Please let us know what could be the probable cause that our API's were not 
> able to connect to SOLR nodes completely which resulted in Production 
> downtime.
> Thanks
> Pahuni



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9547) Do not allow bin/solr start as root user (unless -force param specified)

[JIRA]

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

Jan Høydahl commented on SOLR-9547:
---

Documented in refGuide
https://cwiki.apache.org/confluence/display/solr/Solr+Start+Script+Reference
https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production

> Do not allow bin/solr start as root user (unless -force param specified)
> 
>
> Key: SOLR-9547
> URL: https://issues.apache.org/jira/browse/SOLR-9547
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9547.patch
>
>
> Spinoff from SOLR-7826
> We should abort with a warning if user tries to start Solr as root, since 
> this is simply not recommended and poses a security threat.
> We should do the same for the "restart" option.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9411) Better validation for Schema API

[JIRA]

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

Jan Høydahl updated SOLR-9411:
--
Fix Version/s: master (7.0)
   6.3

> Better validation for Schema API
> 
>
> Key: SOLR-9411
> URL: https://issues.apache.org/jira/browse/SOLR-9411
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9411.patch
>
>
> Schema REST API needs better validation before doing changes.
> * It should not be allowed to delete uniqueKey (also handled in SOLR-9349)
> * When adding a dynamic field the API should test that it begins or ends with 
> {{*}}. Today the change succeeds, but you get errors later
> These are two known cases. We should harden validation across the board for 
> all known schema requirements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Deleting multiple comments from Confluence

[Jan Høydahl]

Seems I don’t have permissions to delete multiple comments from a Confluence 
page anymore.
I click the link “Delete comments” on a comment (e.g 
https://cwiki.apache.org/confluence/plugins/aptis/deleteAllComments/ask-user.action?pageId=32604161)
and is shown an error msg "No valid License”. This used to work before, and is 
time saving when cleaning up old cruft.

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


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