Re: Index corruption on NTFS
Crazy. It would be helpful if you could provide a repro of this as a small Java program one could run on a (small) NTFS partition (perhaps beasting it over and over to simulate this effect?). Dawid On Tue, Nov 8, 2016 at 5:04 AM, Thomas Kappler wrote: > Hi all, > > > > We’re occasionally observing corrupted indexes in production, on Windows > Server. We tracked it down to the way NTFS behaves in case of partial > writes. > > > > When the disk or the machine fail during a flush, it’s possible on NTFS that > the file being written to has already been extended to the new length, but > the content is not visible yet. For security reasons NTFS will return all 0s > for content when reading past the last successfully written point after the > system restarts. > > > > Lucene's commit code relies on committing an updated .gen file as the last > step of index flush/update. In this case, the file is there, but contains > 0s, making it unreadable for Lucene. Failures at this point leave the index > in a state that's not readable. > > > > We think that the safest approach, which is robust to reordered writes, is > to consider a gen file with all zeroes the same as a non-existing gen file. > This assumes that by the time the gen file is fsync'ed all other files have > been flushed to disk explicitly. If that's not the case, then there's still > exposure to reordered writes. > > > > I don’t have a repro at this point. Before digging deeper into this I wanted > to see what the Lucene devs think. Does the proposed fix make sense? Any > ideas on how to set up a reproducible test for this issue? > > > > We verified this on Elasticsearch 1.7.1 which uses Lucene 4.10.4. Are there > significant changes to this area in newer Lucene versions? > > > > // Thomas > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7544) UnifiedHighlighter should allow extension for custom query types
[ https://issues.apache.org/jira/browse/LUCENE-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-7544: - Attachment: LUCENE-7544.patch Here's the patch with some tweaks. "ant precommit" found some issues, which I fixed. I modified MultiTermHighlighting a bit to avoid the need for the extra indentation. It's hard to describe; you can see for yourself. I tweaked the param name too. Let me know if you like it; I'll probably commit Tuesday evening, barring substantive changes. > UnifiedHighlighter should allow extension for custom query types > > > Key: LUCENE-7544 > URL: https://issues.apache.org/jira/browse/LUCENE-7544 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Reporter: Michael Braun >Assignee: David Smiley > Fix For: 6.4 > > Attachments: LUCENE-7544.patch > > > In our use case, we have custom query types (both SpanQuery and > non-SpanQuery) which are not provided by Lucene. UnifiedHighlighter needs > extension points to handle some custom query types in order for highlighting > to be accurate. This issue represents adding two extension point methods to > support custom query types. -- 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-6.3 - Build # 5 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.3/5/
1 tests failed.
FAILED:
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality.test
Error Message:
int_i: goodEst=13946, poorEst=13970, real=13975,
p=q=id:[284+TO+14258]&rows=0&stats=true&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_int_i}int_i&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_int_i_prehashed_l+hllPreHashed%3Dtrue}int_i_prehashed_l&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_int_i}int_i&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_int_i_prehashed_l+hllPreHashed%3Dtrue}int_i_prehashed_l&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_long_l}long_l&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_long_l_prehashed_l+hllPreHashed%3Dtrue}long_l_prehashed_l&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_long_l}long_l&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_long_l_prehashed_l+hllPreHashed%3Dtrue}long_l_prehashed_l&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_string_s}string_s&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_string_s_prehashed_l+hllPreHashed%3Dtrue}string_s_prehashed_l&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_string_s}string_s&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_string_s_prehashed_l+hllPreHashed%3Dtrue}string_s_prehashed_l
Stack Trace:
java.lang.AssertionError: int_i: goodEst=13946, poorEst=13970, real=13975,
p=q=id:[284+TO+14258]&rows=0&stats=true&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_int_i}int_i&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_int_i_prehashed_l+hllPreHashed%3Dtrue}int_i_prehashed_l&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_int_i}int_i&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_int_i_prehashed_l+hllPreHashed%3Dtrue}int_i_prehashed_l&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_long_l}long_l&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_long_l_prehashed_l+hllPreHashed%3Dtrue}long_l_prehashed_l&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_long_l}long_l&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_long_l_prehashed_l+hllPreHashed%3Dtrue}long_l_prehashed_l&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_string_s}string_s&stats.field={!cardinality%3D0.01300996095014778+key%3Dlow_string_s_prehashed_l+hllPreHashed%3Dtrue}string_s_prehashed_l&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_string_s}string_s&stats.field={!cardinality%3D0.5130099609501477+key%3Dhigh_string_s_prehashed_l+hllPreHashed%3Dtrue}string_s_prehashed_l
at
__randomizedtesting.SeedInfo.seed([D0DA16F367EE3305:588E2929C9125EFD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality.test(TestDistributedStatsComponentCardinality.java:217)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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(ThreadLea
[jira] [Commented] (SOLR-9688) Add a command-line tool to manage the snapshots functionality
[ https://issues.apache.org/jira/browse/SOLR-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15646522#comment-15646522 ] Yonik Seeley commented on SOLR-9688: Looks fine to me! I can commit probably tomorrow, and then we still have until 6.4 is released to freely make API changes. > Add a command-line tool to manage the snapshots functionality > - > > Key: SOLR-9688 > URL: https://issues.apache.org/jira/browse/SOLR-9688 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Hrishikesh Gadre >Priority: Minor > -- 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
Index corruption on NTFS
Hi all, We're occasionally observing corrupted indexes in production, on Windows Server. We tracked it down to the way NTFS behaves in case of partial writes. When the disk or the machine fail during a flush, it's possible on NTFS that the file being written to has already been extended to the new length, but the content is not visible yet. For security reasons NTFS will return all 0s for content when reading past the last successfully written point after the system restarts. Lucene's commit code relies on committing an updated .gen file as the last step of index flush/update. In this case, the file is there, but contains 0s, making it unreadable for Lucene. Failures at this point leave the index in a state that's not readable. We think that the safest approach, which is robust to reordered writes, is to consider a gen file with all zeroes the same as a non-existing gen file. This assumes that by the time the gen file is fsync'ed all other files have been flushed to disk explicitly. If that's not the case, then there's still exposure to reordered writes. I don't have a repro at this point. Before digging deeper into this I wanted to see what the Lucene devs think. Does the proposed fix make sense? Any ideas on how to set up a reproducible test for this issue? We verified this on Elasticsearch 1.7.1 which uses Lucene 4.10.4. Are there significant changes to this area in newer Lucene versions? // Thomas
[jira] [Commented] (SOLR-8335) HdfsLockFactory does not allow core to come up after a node was killed
[
https://issues.apache.org/jira/browse/SOLR-8335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15646335#comment-15646335
]
胡晓东 commented on SOLR-8335:
---
In solr cloud mode ,can I use solr.lock.type=none instead of
solr.lock.type=hdfs?
> HdfsLockFactory does not allow core to come up after a node was killed
> --
>
> Key: SOLR-8335
> URL: https://issues.apache.org/jira/browse/SOLR-8335
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Varun Thacker
>
> When using HdfsLockFactory if a node gets killed instead of a graceful
> shutdown the write.lock file remains in HDFS . The next time you start the
> node the core doesn't load up because of LockObtainFailedException .
> I was able to reproduce this in all 5.x versions of Solr . The problem wasn't
> there when I tested it in 4.10.4
> Steps to reproduce this on 5.x
> 1. Create directory in HDFS : {{bin/hdfs dfs -mkdir /solr}}
> 2. Start Solr: {{bin/solr start -Dsolr.directoryFactory=HdfsDirectoryFactory
> -Dsolr.lock.type=hdfs -Dsolr.data.dir=hdfs://localhost:9000/solr
> -Dsolr.updatelog=hdfs://localhost:9000/solr}}
> 3. Create core: {{./bin/solr create -c test -n data_driven}}
> 4. Kill solr
> 5. The lock file is there in HDFS and is called {{write.lock}}
> 6. Start Solr again and you get a stack trace like this:
> {code}
> 2015-11-23 13:28:04.287 ERROR (coreLoadExecutor-6-thread-1) [ x:test]
> o.a.s.c.CoreContainer Error creating core [test]: Index locked for write for
> core 'test'. Solr now longer supports forceful unlocking via
> 'unlockOnStartup'. Please verify locks manually!
> org.apache.solr.common.SolrException: Index locked for write for core 'test'.
> Solr now longer supports forceful unlocking via 'unlockOnStartup'. Please
> verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked
> for write for core 'test'. Solr now longer supports forceful unlocking via
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:528)
> at org.apache.solr.core.SolrCore.(SolrCore.java:761)
> ... 9 more
> 2015-11-23 13:28:04.289 ERROR (coreContainerWorkExecutor-2-thread-1) [ ]
> o.a.s.c.CoreContainer Error waiting for SolrCore to be created
> java.util.concurrent.ExecutionException:
> org.apache.solr.common.SolrException: Unable to create core [test]
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.apache.solr.core.CoreContainer$2.run(CoreContainer.java:472)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.solr.common.SolrException: Unable to create core [test]
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:737)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: Index locked for write for
> core 'test'. Solr now longer supports forceful unlocking via
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> ... 7 more
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked
> for wr
Re: VOTE: Apache Solr Reference Guide for Solr 6.3
I see a problem as well. I'll make the change. Joel Bernstein http://joelsolr.blogspot.com/ On Mon, Nov 7, 2016 at 7:22 PM, Steve Rowe wrote: > I found a few problems that I think warrant a respin - I’ll go make edits > now: > > > Upgrading Solr (pg. 29): > > "If you are already using Solr 6.1, Solr 6.2 should not present any major > problems.” >-> Wrong version numbers: these should be 6.2 and 6.3. > > > Response Writers | Velocity Response Writer >VelocityResponseWriter initialization parameters (pg. 414): > -> Second table column content is truncated > > > Implicit RequestHandlers (pg. 559) >-> “Description” table column content is truncated > > -- > Steve > www.lucidworks.com > > > On Nov 7, 2016, at 5:00 PM, Cassandra Targett > wrote: > > > > Please VOTE to release the Solr Reference Guide for 6.3. > > > > The artifacts are available here: > > https://dist.apache.org/repos/dist/dev/lucene/solr/ref- > guide/apache-solr-ref-guide-6.3-RC1/ > > > > (I normally start with RC0, but missed updating the javadoc links > > after I'd already committed RC0, so we'll just start with RC1 and I'll > > clean up the extra dir later.) > > > > $ more apache-solr-ref-guide-6.3-RC1/apache-solr-ref-guide-6.3.pdf.sha1 > > eba6a836e9536283cb4f23e4ca4bccf8cd1ee3bd apache-solr-ref-guide-6.3.pdf > > > > Here is my +1. > > > > Thanks, > > Cassandra > > > > - > > 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-9736) HttpSolrCall always prefer leader
[ https://issues.apache.org/jira/browse/SOLR-9736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-9736: --- Attachment: SOLR-9736.patch Cleaner patch for this issue. > HttpSolrCall always prefer leader > - > > Key: SOLR-9736 > URL: https://issues.apache.org/jira/browse/SOLR-9736 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat > Attachments: SOLR-9736.patch, SOLR-9736.patch > > > Currently, `HttpSolrCall.getCoreByCollection` always picks the first > available leader ( or first replica ) of the first slice. It puts undue > pressure on leaders and quite possibly on the wrong ones -- 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-7543) Make changes-to-html target an offline operation
[
https://issues.apache.org/jira/browse/LUCENE-7543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15646028#comment-15646028
]
Alexandre Rafalovitch commented on LUCENE-7543:
---
Just to clarify.
Currently the (perl) script pulls the information from JIRA, right? So, it is
maintained as part of the issue tagging/release process.
So, what uses doap.rdf and how is it kept up to date? And if it is moved to
GitHub, do we abandon the original location/processes?
> Make changes-to-html target an offline operation
>
>
> Key: LUCENE-7543
> URL: https://issues.apache.org/jira/browse/LUCENE-7543
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Steve Rowe
>
> Currently changes-to-html pulls release dates from JIRA, and so fails when
> JIRA is inaccessible (e.g. from behind a firewall).
> SOLR-9711 advocates adding a build sysprop to ignore JIRA connection
> failures, but I'd rather make the operation always offline.
> In an offline discussion, [~hossman] advocated moving Lucene's and Solr's
> {{doap.rdf}} files, which contain all of the release dates that the
> changes-to-html now pulls from JIRA, from the CMS Subversion repository
> (downloadable from the website at http://lucene.apache.org/core/doap.rdf and
> http://lucene.apache.org/solr/doap.rdf) to the Lucene/Solr git repository. If
> we did that, then the process could be entirely offline if release dates were
> taken from the local {{doap.rdf}} files instead of downloaded from JIRA.
--
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: VOTE: Apache Solr Reference Guide for Solr 6.3
I found a few problems that I think warrant a respin - I’ll go make edits now: Upgrading Solr (pg. 29): "If you are already using Solr 6.1, Solr 6.2 should not present any major problems.” -> Wrong version numbers: these should be 6.2 and 6.3. Response Writers | Velocity Response Writer VelocityResponseWriter initialization parameters (pg. 414): -> Second table column content is truncated Implicit RequestHandlers (pg. 559) -> “Description” table column content is truncated -- Steve www.lucidworks.com > On Nov 7, 2016, at 5:00 PM, Cassandra Targett wrote: > > Please VOTE to release the Solr Reference Guide for 6.3. > > The artifacts are available here: > https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.3-RC1/ > > (I normally start with RC0, but missed updating the javadoc links > after I'd already committed RC0, so we'll just start with RC1 and I'll > clean up the extra dir later.) > > $ more apache-solr-ref-guide-6.3-RC1/apache-solr-ref-guide-6.3.pdf.sha1 > eba6a836e9536283cb4f23e4ca4bccf8cd1ee3bd apache-solr-ref-guide-6.3.pdf > > Here is my +1. > > Thanks, > Cassandra > > - > 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
Problems Running ant enwiki
Anyone else having problems retrieving the test wikipedia set used for benchmarks? It looks like the resource is no longer available. When I run ant enwiki I receive the following: [get] Error opening connection java.io.FileNotFoundException:http://people.apache.org/~gsingers/wikipedia/enwiki- 20070527-pages-articles.xml.bz2 I've tried the link directly from a browser and it looks like it's moved. Is there a mirror someplace? -Tim
[GitHub] lucene-solr pull request #111: LUCENE-7544 - add UnifiedHighlighter extensio...
Github user michaelbraun commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/111#discussion_r86893258
--- Diff:
lucene/highlighter/src/test/org/apache/lucene/search/uhighlight/TestUnifiedHighlighter.java
---
@@ -959,4 +961,84 @@ protected PassageFormatter getFormatter(String field) {
ir.close();
}
+ public void testBooleanWithSpanAndOverlappingTerms() throws IOException {
--- End diff --
I will fix the name of the test to clarify and move to the appropriate
file. Regarding PhraseHelper, that should probably be a separate issue/commit
I'd think, no? Agree it should be have package visibility rather than be public.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7544) UnifiedHighlighter should allow extension for custom query types
[
https://issues.apache.org/jira/browse/LUCENE-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645801#comment-15645801
]
ASF GitHub Bot commented on LUCENE-7544:
Github user michaelbraun commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/111#discussion_r86893258
--- Diff:
lucene/highlighter/src/test/org/apache/lucene/search/uhighlight/TestUnifiedHighlighter.java
---
@@ -959,4 +961,84 @@ protected PassageFormatter getFormatter(String field) {
ir.close();
}
+ public void testBooleanWithSpanAndOverlappingTerms() throws IOException {
--- End diff --
I will fix the name of the test to clarify and move to the appropriate
file. Regarding PhraseHelper, that should probably be a separate issue/commit
I'd think, no? Agree it should be have package visibility rather than be public.
> UnifiedHighlighter should allow extension for custom query types
>
>
> Key: LUCENE-7544
> URL: https://issues.apache.org/jira/browse/LUCENE-7544
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/highlighter
>Reporter: Michael Braun
>Assignee: David Smiley
> Fix For: 6.4
>
>
> In our use case, we have custom query types (both SpanQuery and
> non-SpanQuery) which are not provided by Lucene. UnifiedHighlighter needs
> extension points to handle some custom query types in order for highlighting
> to be accurate. This issue represents adding two extension point methods to
> support custom query types.
--
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-9725) Allow Variables for All Data Import Handler Data Source Configuration Values
[
https://issues.apache.org/jira/browse/SOLR-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645715#comment-15645715
]
Jamie Jackson commented on SOLR-9725:
-
Probably not from me, unless someone's prepared to do a lot of hand-holding. At
a quick glance, it doesn't look too easy (for _me_, anyway) to add this test to
[{{TestSqlEntityProcessor}}|https://github.com/apache/lucene-solr/tree/branch_5x/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport].
> Allow Variables for All Data Import Handler Data Source Configuration Values
>
>
> Key: SOLR-9725
> URL: https://issues.apache.org/jira/browse/SOLR-9725
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Affects Versions: 5.5.3
>Reporter: Jamie Jackson
>Priority: Minor
> Labels: patch
>
> I need to be able to use a variable for a password when also using
> {{encryptKeyFile}}.
> For instance:
> {code:xml}
> driver="${custom.dataimporter.datasource.driver}"
> url="${custom.dataimporter.datasource.url}"
> user="${custom.dataimporter.datasource.user}"
> password="${custom.dataimporter.datasource.password}"
> encryptKeyFile="/opt/solr/credentials/encrypt.key"
> />
> {code}
> Because I need to change certain variables based on the environment. I'd
> start like this:
> {code}
> -a
> -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
>
> -Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
> -Dcustom.dataimporter.datasource.user=root
>
> -Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
> {code}
> If I hardcode the password, it works; if I use a variable reference, it
> doesn't.
> As far as I know [this pull
> request|https://github.com/apache/lucene-solr/pull/46] was submitted to
> address this issue, but it didn't come with a Jira ticket or a full
> explanation.
> Also, note that I'm not using a variable for the value of {{encryptKeyFile}},
> because [it's not possible in 5.x, though it seems to be fixed in
> 6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above
> patch would encompass {{encryptKeyFile}}'s value, as well.
--
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-7544) UnifiedHighlighter should allow extension for custom query types
[
https://issues.apache.org/jira/browse/LUCENE-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645655#comment-15645655
]
ASF GitHub Bot commented on LUCENE-7544:
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/111#discussion_r86882518
--- Diff:
lucene/highlighter/src/test/org/apache/lucene/search/uhighlight/TestUnifiedHighlighter.java
---
@@ -959,4 +961,84 @@ protected PassageFormatter getFormatter(String field) {
ir.close();
}
+ public void testBooleanWithSpanAndOverlappingTerms() throws IOException {
--- End diff --
Can you please simplify this one... it's ultimately testing
preSpanQueryRewrite... maybe make it clear that it's testing that by naming the
test method as-such? Maybe this test should go into
TestUnifiedHighlighterStrictPhrases as it's pertinent to that and not general
stuff.
> UnifiedHighlighter should allow extension for custom query types
>
>
> Key: LUCENE-7544
> URL: https://issues.apache.org/jira/browse/LUCENE-7544
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/highlighter
>Reporter: Michael Braun
>Assignee: David Smiley
> Fix For: 6.4
>
>
> In our use case, we have custom query types (both SpanQuery and
> non-SpanQuery) which are not provided by Lucene. UnifiedHighlighter needs
> extension points to handle some custom query types in order for highlighting
> to be accurate. This issue represents adding two extension point methods to
> support custom query types.
--
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
[GitHub] lucene-solr pull request #111: LUCENE-7544 - add UnifiedHighlighter extensio...
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/111#discussion_r86882518
--- Diff:
lucene/highlighter/src/test/org/apache/lucene/search/uhighlight/TestUnifiedHighlighter.java
---
@@ -959,4 +961,84 @@ protected PassageFormatter getFormatter(String field) {
ir.close();
}
+ public void testBooleanWithSpanAndOverlappingTerms() throws IOException {
--- End diff --
Can you please simplify this one... it's ultimately testing
preSpanQueryRewrite... maybe make it clear that it's testing that by naming the
test method as-such? Maybe this test should go into
TestUnifiedHighlighterStrictPhrases as it's pertinent to that and not general
stuff.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
VOTE: Apache Solr Reference Guide for Solr 6.3
Please VOTE to release the Solr Reference Guide for 6.3. The artifacts are available here: https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.3-RC1/ (I normally start with RC0, but missed updating the javadoc links after I'd already committed RC0, so we'll just start with RC1 and I'll clean up the extra dir later.) $ more apache-solr-ref-guide-6.3-RC1/apache-solr-ref-guide-6.3.pdf.sha1 eba6a836e9536283cb4f23e4ca4bccf8cd1ee3bd apache-solr-ref-guide-6.3.pdf Here is my +1. Thanks, Cassandra - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7544) UnifiedHighlighter should allow extension for custom query types
[ https://issues.apache.org/jira/browse/LUCENE-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-7544: - Assignee: David Smiley Fix Version/s: 6.4 Component/s: modules/highlighter > UnifiedHighlighter should allow extension for custom query types > > > Key: LUCENE-7544 > URL: https://issues.apache.org/jira/browse/LUCENE-7544 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Reporter: Michael Braun >Assignee: David Smiley > Fix For: 6.4 > > > In our use case, we have custom query types (both SpanQuery and > non-SpanQuery) which are not provided by Lucene. UnifiedHighlighter needs > extension points to handle some custom query types in order for highlighting > to be accurate. This issue represents adding two extension point methods to > support custom query types. -- 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-7544) UnifiedHighlighter should allow extension for custom query types
[ https://issues.apache.org/jira/browse/LUCENE-7544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645409#comment-15645409 ] ASF GitHub Bot commented on LUCENE-7544: GitHub user michaelbraun opened a pull request: https://github.com/apache/lucene-solr/pull/111 LUCENE-7544 - add UnifiedHighlighter extension points for custom queries You can merge this pull request into a Git repository by running: $ git pull https://github.com/michaelbraun/lucene-solr lucene-7544 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/111.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #111 commit 871c6d24bca90e32a3c5dc3de54dd48d6229ffc7 Author: Michael Braun Date: 2016-11-07T20:36:41Z LUCENE-7544 - add UnifiedHighlighter extension points for custom queries > UnifiedHighlighter should allow extension for custom query types > > > Key: LUCENE-7544 > URL: https://issues.apache.org/jira/browse/LUCENE-7544 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun > > In our use case, we have custom query types (both SpanQuery and > non-SpanQuery) which are not provided by Lucene. UnifiedHighlighter needs > extension points to handle some custom query types in order for highlighting > to be accurate. This issue represents adding two extension point methods to > support custom query types. -- 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
[GitHub] lucene-solr pull request #111: LUCENE-7544 - add UnifiedHighlighter extensio...
GitHub user michaelbraun opened a pull request: https://github.com/apache/lucene-solr/pull/111 LUCENE-7544 - add UnifiedHighlighter extension points for custom queries You can merge this pull request into a Git repository by running: $ git pull https://github.com/michaelbraun/lucene-solr lucene-7544 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/111.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #111 commit 871c6d24bca90e32a3c5dc3de54dd48d6229ffc7 Author: Michael Braun Date: 2016-11-07T20:36:41Z LUCENE-7544 - add UnifiedHighlighter extension points for custom queries --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7544) UnifiedHighlighter should allow extension for custom query types
Michael Braun created LUCENE-7544: - Summary: UnifiedHighlighter should allow extension for custom query types Key: LUCENE-7544 URL: https://issues.apache.org/jira/browse/LUCENE-7544 Project: Lucene - Core Issue Type: Improvement Reporter: Michael Braun In our use case, we have custom query types (both SpanQuery and non-SpanQuery) which are not provided by Lucene. UnifiedHighlighter needs extension points to handle some custom query types in order for highlighting to be accurate. This issue represents adding two extension point methods to support custom query types. -- 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: [JENKINS] Lucene-Solr-Tests-6.x - Build # 525 - Still Failing
Woops, I'll fix ... Mike McCandless http://blog.mikemccandless.com On Mon, Nov 7, 2016 at 2:34 PM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/525/ > > All tests passed > > Build Log: > [...truncated 55759 lines...] > changes-to-html: > [mkdir] Created dir: > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/build/docs/changes > [get] Getting: https://issues.apache.org/jira/rest/api/2/project/LUCENE > [get] To: > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/build/docs/changes/jiraVersionList.json > [exec] Section 'Improvements' appears more than once under release > '6.4.0' at > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/site/changes/changes2html.pl > line 135. > > BUILD FAILED > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/build.xml:765: The > following error occurred while executing this line: > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/build.xml:101: The > following error occurred while executing this line: > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/build.xml:138: > The following error occurred while executing this line: > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/build.xml:479: > The following error occurred while executing this line: > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/common-build.xml:2514: > exec returned: 255 > > Total time: 94 minutes 42 seconds > Build step 'Invoke Ant' marked build as failure > Archiving artifacts > Recording test results > Email was triggered for: Failure - Any > Sending email for trigger: Failure - Any > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-6.x - Build # 525 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/525/ All tests passed Build Log: [...truncated 55759 lines...] changes-to-html: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/build/docs/changes [get] Getting: https://issues.apache.org/jira/rest/api/2/project/LUCENE [get] To: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/build/docs/changes/jiraVersionList.json [exec] Section 'Improvements' appears more than once under release '6.4.0' at /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/site/changes/changes2html.pl line 135. BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/build.xml:765: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/build.xml:101: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/build.xml:138: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/build.xml:479: The following error occurred while executing this line: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/lucene/common-build.xml:2514: exec returned: 255 Total time: 94 minutes 42 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645187#comment-15645187 ] Dawid Weiss commented on SOLR-9293: --- I don't think we have any formal processes (if I understand your acronyms right). To me common sense and trust I have in other people's judgement typically works best. This applies to both when asking for help on solutions I'm not so confident in and when I think there's simply not that much to discuss because the patch/commit is trivial or self-explanatory. This particular issue was filed by me a good while ago, it doesn't change anything in terms of existing functionality and it patched a functional hole with means that are neither controversial, nor that difficult to understand. I honestly didn't think it was worth bothering people with requests for reviews of something that is, in essence, a trivial extension of existing code. Obviously you do have the right to speak up if there's something wrong with a commit. And I'm more then willing to revert and reiterate if this is the case. > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0), 6.4 > > -- 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-9633) Limit FastLRUCache by RAM Usage
[ https://issues.apache.org/jira/browse/SOLR-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645182#comment-15645182 ] Yonik Seeley commented on SOLR-9633: OK, thanks for the explanation. That's clearer after I apply the patch too. Things look good... I think the only minor change I'd make is to wrap the other update to ramBytes in the put() method with the "ramUpperWatermark != Long.MAX_VALUE" check as you did in other places. > Limit FastLRUCache by RAM Usage > --- > > Key: SOLR-9633 > URL: https://issues.apache.org/jira/browse/SOLR-9633 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar > Fix For: 6.3, master (7.0) > > Attachments: SOLR-9633.patch > > > SOLR-7372 added a maxRamMB parameter to LRUCache to evict items based on > memory usage. That helps with the query result cache but not with the filter > cache which defaults to FastLRUCache. This issue intends to add the same > feature to FastLRUCache. -- 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-9728) Ability to specify Key Store type in solr.in file for SSL
[
https://issues.apache.org/jira/browse/SOLR-9728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Suzuki updated SOLR-9728:
-
Assignee: (was: Michael Suzuki)
> Ability to specify Key Store type in solr.in file for SSL
> -
>
> Key: SOLR-9728
> URL: https://issues.apache.org/jira/browse/SOLR-9728
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
> Attachments: SOLR-9728.patch
>
>
> At present when ssl is enabled we can't set the SSL type. It currently
> defaults to JCK.
> As a user I would like to configure the SSL type via the solr.in file.
> For instance "JCEKS" would be configured as:
> {code}
> SOLR_SSL_KEYSTORE_TYPE=JCEKS
> SOLR_SSL_TRUSTSTORE_TYPE=JCEKS
> {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-9727) solr.in.sh properties does not set the correct values.
[
https://issues.apache.org/jira/browse/SOLR-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Suzuki updated SOLR-9727:
-
Assignee: (was: Michael Suzuki)
> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false.
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.
--
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-9726) DocValuesFacets: move 'contains' check after 'min' check
[ https://issues.apache.org/jira/browse/SOLR-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645039#comment-15645039 ] ASF subversion and git services commented on SOLR-9726: --- Commit 1c7ae9215cbb276a89ae17fd95a43c54ef582a68 in lucene-solr's branch refs/heads/branch_6x from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1c7ae92 ] SOLR-9726: Reduce number of lookupOrd calls made by the DocValuesFacets.getCounts method. (Jonny Marks via Christine Poerschke) > DocValuesFacets: move 'contains' check after 'min' check > > > Key: SOLR-9726 > URL: https://issues.apache.org/jira/browse/SOLR-9726 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jonny Marks >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-9726.patch > > > If a query requests facets with a 'contains' check, DocValuesFacets converts > each term's ordinal to a BytesRef, does the string match and then checks > whether it has a high enough count to go in the priority queue. > This patch moves the lookup after the min check so that we don't do it for > all terms. -- 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-9726) DocValuesFacets: move 'contains' check after 'min' check
[ https://issues.apache.org/jira/browse/SOLR-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644982#comment-15644982 ] ASF subversion and git services commented on SOLR-9726: --- Commit cbf8235e570c8f10f42eb1240f7e0d5918e7025c in lucene-solr's branch refs/heads/master from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cbf8235 ] SOLR-9726: Reduce number of lookupOrd calls made by the DocValuesFacets.getCounts method. (Jonny Marks via Christine Poerschke) > DocValuesFacets: move 'contains' check after 'min' check > > > Key: SOLR-9726 > URL: https://issues.apache.org/jira/browse/SOLR-9726 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jonny Marks >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-9726.patch > > > If a query requests facets with a 'contains' check, DocValuesFacets converts > each term's ordinal to a BytesRef, does the string match and then checks > whether it has a high enough count to go in the priority queue. > This patch moves the lookup after the min check so that we don't do it for > all terms. -- 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-9711) Build parameter to silence Changes.html generation error if SOLR Jira is not accessible
[ https://issues.apache.org/jira/browse/SOLR-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644953#comment-15644953 ] Steve Rowe commented on SOLR-9711: -- See LUCENE-7543. > Build parameter to silence Changes.html generation error if SOLR Jira is not > accessible > --- > > Key: SOLR-9711 > URL: https://issues.apache.org/jira/browse/SOLR-9711 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mano Kovacs > Labels: build > Attachments: SOLR-9711.patch > > > In case the build is running behind firewall with no access to > issues.apache.org, generation of Changes.html fails, failing the entire build. > Supporting a -Dchanges.ignoreError parameter, that skips generation of html > file upon network, would solve the issue. -- 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] (LUCENE-7543) Make changes-to-html target an offline operation
Steve Rowe created LUCENE-7543:
--
Summary: Make changes-to-html target an offline operation
Key: LUCENE-7543
URL: https://issues.apache.org/jira/browse/LUCENE-7543
Project: Lucene - Core
Issue Type: Task
Reporter: Steve Rowe
Currently changes-to-html pulls release dates from JIRA, and so fails when JIRA
is inaccessible (e.g. from behind a firewall).
SOLR-9711 advocates adding a build sysprop to ignore JIRA connection failures,
but I'd rather make the operation always offline.
In an offline discussion, [~hossman] advocated moving Lucene's and Solr's
{{doap.rdf}} files, which contain all of the release dates that the
changes-to-html now pulls from JIRA, from the CMS Subversion repository
(downloadable from the website at http://lucene.apache.org/core/doap.rdf and
http://lucene.apache.org/solr/doap.rdf) to the Lucene/Solr git repository. If
we did that, then the process could be entirely offline if release dates were
taken from the local {{doap.rdf}} files instead of downloaded from JIRA.
--
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] [Moved] (LUCENE-7542) Release smoker should fail when CHANGES.txt has a release section for a future release
[ https://issues.apache.org/jira/browse/LUCENE-7542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe moved SOLR-9737 to LUCENE-7542: -- Security: (was: Public) Issue Type: Task (was: Bug) Key: LUCENE-7542 (was: SOLR-9737) Project: Lucene - Core (was: Solr) > Release smoker should fail when CHANGES.txt has a release section for a > future release > -- > > Key: LUCENE-7542 > URL: https://issues.apache.org/jira/browse/LUCENE-7542 > Project: Lucene - Core > Issue Type: Task >Reporter: Steve Rowe > > In the first 6.3.0 RC, Solr's CHANGES.txt had a section for 7.0.0. > smokeTestRelease.py should add a new check for future release sections and > fail if any are found. -- 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-9659) Add zookeeper DataWatch API
[ https://issues.apache.org/jira/browse/SOLR-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644915#comment-15644915 ] Scott Blum commented on SOLR-9659: -- If you want to throw me a PR I'll do my best to review it. I'm just noting that it's hard to ensure this kind of code is bug free on inspection. It took several iterations to iron out bugs and race conditions to the new features in ZKStateReader. You might as well press forward if you're convinced this is the right path, since you're the one with the burning desire to make progress here. :) > Add zookeeper DataWatch API > --- > > Key: SOLR-9659 > URL: https://issues.apache.org/jira/browse/SOLR-9659 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: SOLR-9659.patch > > > We have several components which need to set up watches on ZooKeeper nodes > for various aspects of cluster management. At the moment, all of these > components do this themselves, leading to large amounts of duplicated code, > and complicated logic for dealing with reconnections, etc, scattered across > the codebase. We should replace this with a simple API controlled by > SolrZkClient, which should make the code more robust, and testing > considerably easier. -- 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-9737) Release smoker should fail when CHANGES.txt has a release section for a future release
Steve Rowe created SOLR-9737: Summary: Release smoker should fail when CHANGES.txt has a release section for a future release Key: SOLR-9737 URL: https://issues.apache.org/jira/browse/SOLR-9737 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Steve Rowe In the first 6.3.0 RC, Solr's CHANGES.txt had a section for 7.0.0. smokeTestRelease.py should add a new check for future release sections and fail if any are found. -- 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-9711) Build parameter to silence Changes.html generation error if SOLR Jira is not accessible
[ https://issues.apache.org/jira/browse/SOLR-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644905#comment-15644905 ] Steve Rowe commented on SOLR-9711: -- bq. Do you think it would possible to add this short term alternative as a quick win and remove it altogether when the doap.rdf is moved? I'd rather not add a build system property for such a narrow problem, which will then be removed. I'll make a new issue for the doap.rdf move now, and hopefully I'll get a patch for it out this week. > Build parameter to silence Changes.html generation error if SOLR Jira is not > accessible > --- > > Key: SOLR-9711 > URL: https://issues.apache.org/jira/browse/SOLR-9711 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mano Kovacs > Labels: build > Attachments: SOLR-9711.patch > > > In case the build is running behind firewall with no access to > issues.apache.org, generation of Changes.html fails, failing the entire build. > Supporting a -Dchanges.ignoreError parameter, that skips generation of html > file upon network, would solve the issue. -- 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 (64bit/jdk1.8.0_102) - Build # 2125 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2125/ Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 55796 lines...] changes-to-html: [mkdir] Created dir: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/docs/changes [get] Getting: https://issues.apache.org/jira/rest/api/2/project/LUCENE [get] To: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/docs/changes/jiraVersionList.json [exec] Section 'Improvements' appears more than once under release '6.4.0' at /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/site/changes/changes2html.pl line 135. BUILD FAILED /home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:765: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:101: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build.xml:138: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build.xml:479: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:2514: exec returned: 255 Total time: 69 minutes 44 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9711) Build parameter to silence Changes.html generation error if SOLR Jira is not accessible
[ https://issues.apache.org/jira/browse/SOLR-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644853#comment-15644853 ] Mano Kovacs commented on SOLR-9711: --- [~steve_rowe], have you had a chance to look at my latest comment? What do you think? > Build parameter to silence Changes.html generation error if SOLR Jira is not > accessible > --- > > Key: SOLR-9711 > URL: https://issues.apache.org/jira/browse/SOLR-9711 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mano Kovacs > Labels: build > Attachments: SOLR-9711.patch > > > In case the build is running behind firewall with no access to > issues.apache.org, generation of Changes.html fails, failing the entire build. > Supporting a -Dchanges.ignoreError parameter, that skips generation of html > file upon network, would solve the issue. -- 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: [VOTE] - Release Lucene/Solr 6.3.0 RC3
This vote has passed. I'll now start the rest of the release process. Thanks to all who voted. On Wed, Nov 2, 2016 at 10:04 PM, Shalin Shekhar Mangar wrote: > Please vote for the third release candidate for Lucene/Solr 6.3.0 > > The artifacts can be downloaded from: > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3- > reva66a44513ee8191e25b477372094bfa846450316 > > You can run the smoke tester directly with this command: > python3 -u dev-tools/scripts/smokeTestRelease.py > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3- > reva66a44513ee8191e25b477372094bfa846450316 > > Smoke tester passed for me: > SUCCESS! [0:36:45.760510] > > Here's my +1 to release. > > -- > Regards, > Shalin Shekhar Mangar. > -- Regards, Shalin Shekhar Mangar.
[jira] [Commented] (SOLR-9720) Refactor responsewriter to remove dependencies on TupleStream etc
[ https://issues.apache.org/jira/browse/SOLR-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644681#comment-15644681 ] ASF subversion and git services commented on SOLR-9720: --- Commit 358bdd490b1b15f3af6a355f93a98caf83594b18 in lucene-solr's branch refs/heads/apiv2 from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=358bdd4 ] SOLR-9720: tweak JSONWriter.writeArray > Refactor responsewriter to remove dependencies on TupleStream etc > - > > Key: SOLR-9720 > URL: https://issues.apache.org/jira/browse/SOLR-9720 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-9720.patch, SOLR-9720.patch, SOLR-9720.patch, > SOLR_9720_fix_JSONWriterTest.patch > > > ResponseWriters are designed to be agnostic of components and they should > work with the well know set of types we already support -- 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-6824) TermAutomatonQuery should rewrite to a simpler query when possible
[
https://issues.apache.org/jira/browse/LUCENE-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644688#comment-15644688
]
ASF subversion and git services commented on LUCENE-6824:
-
Commit cc99815dcbaa796d717601d600645e658eb9f882 in lucene-solr's branch
refs/heads/apiv2 from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cc99815 ]
LUCENE-6824: TermAutomatonQuery now rewrites to TermQuery, PhraseQuery or
MultiPhraseQuery when the word automaton is simple
> TermAutomatonQuery should rewrite to a simpler query when possible
> --
>
> Key: LUCENE-6824
> URL: https://issues.apache.org/jira/browse/LUCENE-6824
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.4
>
> Attachments: LUCENE-6824.patch, LUCENE-6824.patch
>
>
> Spinoff from LUCENE-6664.
> I think {{TermAutomatonQuery}} would be easier to integrate into query
> parsers if you could simply use it always and it would rewrite to simpler /
> faster queries when possible.
> This way, when a query parser is confronted with a phrase query requested by
> the user, it can just make a {{TermAutomatonQuery}} and run that.
> But the non-explicit phrase query case is still tricky...
--
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-9005) In files example, update-script.js scripting URP fails with method signature mismatch
[
https://issues.apache.org/jira/browse/SOLR-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644686#comment-15644686
]
ASF subversion and git services commented on SOLR-9005:
---
Commit 9148362617333458e22d7d3c28b26053f4308fa6 in lucene-solr's branch
refs/heads/apiv2 from [~arafalov]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9148362 ]
SOLR-9005: Add guard condition to the example js
> In files example, update-script.js scripting URP fails with method signature
> mismatch
> -
>
> Key: SOLR-9005
> URL: https://issues.apache.org/jira/browse/SOLR-9005
> Project: Solr
> Issue Type: Bug
> Components: examples
>Affects Versions: 6.0
> Environment: Mac
> java version "1.8.0_31"
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9005.patch
>
>
> Following the *files* example README:
> bin/solr start
> bin/solr create -c files -d example/files/conf
> bin/post -c files docs/solr-analytics/index.html # (just one reproducible
> example)
> {noformat}
> Unable to invoke function processAdd in script: update-script.js: Can't
> unambiguously select between fixed arity signatures [(java.lang.String,
> java.io.Reader), (java.lang.String, java.lang.String)] of the method
> org.apache.solr.analysis.TokenizerChain.tokenStream for argument types
> [java.lang.String, null]
> {noformat}
--
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-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644689#comment-15644689 ] ASF subversion and git services commented on SOLR-9293: --- Commit 7fb72bfe10d84d3419b07a8782418f86ab075a56 in lucene-solr's branch refs/heads/apiv2 from [~dawid.weiss] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7fb72bf ] SOLR-9293: Solrj client support for hierarchical clusters and other topics marker. > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0), 6.4 > > -- 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-9005) In files example, update-script.js scripting URP fails with method signature mismatch
[
https://issues.apache.org/jira/browse/SOLR-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644687#comment-15644687
]
ASF subversion and git services commented on SOLR-9005:
---
Commit 284eb77ece6e313f1d309246b48ecdde23228926 in lucene-solr's branch
refs/heads/apiv2 from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=284eb77 ]
SOLR-9005: Remove tabs from solr/example/files/conf/update-script.js.
> In files example, update-script.js scripting URP fails with method signature
> mismatch
> -
>
> Key: SOLR-9005
> URL: https://issues.apache.org/jira/browse/SOLR-9005
> Project: Solr
> Issue Type: Bug
> Components: examples
>Affects Versions: 6.0
> Environment: Mac
> java version "1.8.0_31"
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9005.patch
>
>
> Following the *files* example README:
> bin/solr start
> bin/solr create -c files -d example/files/conf
> bin/post -c files docs/solr-analytics/index.html # (just one reproducible
> example)
> {noformat}
> Unable to invoke function processAdd in script: update-script.js: Can't
> unambiguously select between fixed arity signatures [(java.lang.String,
> java.io.Reader), (java.lang.String, java.lang.String)] of the method
> org.apache.solr.analysis.TokenizerChain.tokenStream for argument types
> [java.lang.String, null]
> {noformat}
--
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-9360) Solr script not properly checking SOLR_PID
[
https://issues.apache.org/jira/browse/SOLR-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644680#comment-15644680
]
ASF subversion and git services commented on SOLR-9360:
---
Commit b2bf87dee7ea1b98eed62ccc3a921d387db39a79 in lucene-solr's branch
refs/heads/apiv2 from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b2bf87d ]
SOLR-9360: Solr script not properly checking SOLR_PID
> Solr script not properly checking SOLR_PID
> --
>
> Key: SOLR-9360
> URL: https://issues.apache.org/jira/browse/SOLR-9360
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Alessandro Benedetti
>Assignee: Erick Erickson
> Fix For: trunk, 6.4
>
> Attachments: SOLR-9360.patch, SOLR-9360.patch, SOLR_9360.patch
>
>
> In the solr script we see in 3-4 areas this check :
> SOLR_PID=`ps auxww | grep start\.jar | grep -w $SOLR_PORT | grep -v grep |
> awk '{print $2}' | sort -r`
> This can potentially prevent a solr instance to start in the case another
> process by any chance contains the port int the command itself ( not
> necessarily actually using the port) .
> e.g.
> java -server -Djetty.port=10504 -DSTOP.PORT=9504 -DSTOP.KEY=solrrocks
> -DMASTER_CORE_URL=external-server:10500/solr -jar start.jar --module=http
> A solr is running on 10504.
> A new Solr will not be able to start on 10500 ( but actually the port is
> free).
> This should be replaced by a real check if the port is used ( like netstat or
> similar) .
--
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-9624) Admin UI (new) query panel does not render csv format
[ https://issues.apache.org/jira/browse/SOLR-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644685#comment-15644685 ] ASF subversion and git services commented on SOLR-9624: --- Commit 94c796968ae9a448aa89f363f055ca4a2958ab10 in lucene-solr's branch refs/heads/apiv2 from [~arafalov] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=94c7969 ] SOLR-9624: Do not highlight CSV output > Admin UI (new) query panel does not render csv format > - > > Key: SOLR-9624 > URL: https://issues.apache.org/jira/browse/SOLR-9624 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UI >Affects Versions: 6.3 >Reporter: Erik Hatcher >Assignee: Alexandre Rafalovitch >Priority: Minor > Fix For: master (7.0), 6.4 > > > The new admin UI query panel does not render wt=csv response, whereas the old > UI does. The top URL gets updated properly, but the results do not render, > leaving the old results there. -- 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-9682) Ability to specify a query with a parameter name (in facet filter)
[ https://issues.apache.org/jira/browse/SOLR-9682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644684#comment-15644684 ] ASF subversion and git services commented on SOLR-9682: --- Commit 4b3e7f2fe2bb7d3bdcd4a2e2d8d786caa281040d in lucene-solr's branch refs/heads/apiv2 from [~yo...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4b3e7f2 ] SOLR-9682: add param query type to facet filter > Ability to specify a query with a parameter name (in facet filter) > -- > > Key: SOLR-9682 > URL: https://issues.apache.org/jira/browse/SOLR-9682 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9682.patch > > > Currently, "filter" only supports query strings (examples at > http://yonik.com/solr-json-request-api/ ) > It would be nice to be able to reference a param that would be parsed as a > lucene/solr query. Multi-valued parameters should be supported. > We should keep in mind (and leave room for) a future "JSON Query Syntax" and > chose labels appropriately. -- 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-9716) RecoveryStrategy send prep recovery cmd without setting request time out
[ https://issues.apache.org/jira/browse/SOLR-9716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644683#comment-15644683 ] ASF subversion and git services commented on SOLR-9716: --- Commit 1f1990d8be9fbbe0d95a10f3be1dffccec969a32 in lucene-solr's branch refs/heads/apiv2 from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1f1990d ] SOLR-9716: RecoveryStrategy sends prep recovery command without setting read time out which can cause replica recovery to hang indefinitely on network partitions > RecoveryStrategy send prep recovery cmd without setting request time out > > > Key: SOLR-9716 > URL: https://issues.apache.org/jira/browse/SOLR-9716 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Shalin Shekhar Mangar > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9716.patch, SOLR-9716.patch, SOLR-9716.patch, > SOLR-9716.patch, SOLR-9716.patch > > > Currently, RecoveryStrategy sends prep recovery cmd without setting request > time out. But this can be long running request, so if we have network > partition in the middle of the request. Recovering core will stay down > forever. -- 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-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644587#comment-15644587 ] David Smiley commented on SOLR-9293: No patch for review first? it's weird this project is officially CTR (not sure where this is declared) yet tons of defacto convention so we're actually RTC. I admit it's tempting to embrace this CTR to just get stuff committed expediently. I hope we all remain open to review comments after-commit. > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0), 6.4 > > -- 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-9659) Add zookeeper DataWatch API
[ https://issues.apache.org/jira/browse/SOLR-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644559#comment-15644559 ] David Smiley commented on SOLR-9659: +1 to Erick's sentiment. > Add zookeeper DataWatch API > --- > > Key: SOLR-9659 > URL: https://issues.apache.org/jira/browse/SOLR-9659 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: SOLR-9659.patch > > > We have several components which need to set up watches on ZooKeeper nodes > for various aspects of cluster management. At the moment, all of these > components do this themselves, leading to large amounts of duplicated code, > and complicated logic for dealing with reconnections, etc, scattered across > the codebase. We should replace this with a simple API controlled by > SolrZkClient, which should make the code more robust, and testing > considerably easier. -- 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-9717) /export should support other formats
[ https://issues.apache.org/jira/browse/SOLR-9717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-9717: - Summary: /export should support other formats (was: "xsort" ResponseWriter should support other formats) > /export should support other formats > > > Key: SOLR-9717 > URL: https://issues.apache.org/jira/browse/SOLR-9717 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-9717.patch > > > The Response JSON is written in an ad hoc way. Standardize the way the docs > are written and support javabin as well -- 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-7955) Auto create .system collection on first request if it does not exist
[
https://issues.apache.org/jira/browse/SOLR-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644547#comment-15644547
]
Noble Paul commented on SOLR-7955:
--
Let's limit the scope to creating the {{.system}} collection during the first
request. I would say let's keep the
{{replicationfactor=Math.min(3,totalNodes)}} . For the time being, it should be
good enough. Users can do ADDREPLICA later
> Auto create .system collection on first request if it does not exist
>
>
> Key: SOLR-7955
> URL: https://issues.apache.org/jira/browse/SOLR-7955
> Project: Solr
> Issue Type: Improvement
>Reporter: Jan Høydahl
> Attachments: SOLR-7955.patch
>
>
> Why should a user need to create the {{.system}} collection manually? It
> would simplify instructions related to BLOB store if user could assume it is
> always there.
--
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-9735) Umbrella JIRA for Cluster Management framework in SolrCloud
[
https://issues.apache.org/jira/browse/SOLR-9735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644546#comment-15644546
]
Erick Erickson commented on SOLR-9735:
--
I think this is somewhat related to SOLR-9731. If we're going to be doing
cluster management, we'll also need to be gathering some metrics about how each
node is doing.
9173 is about exposing metrics on a single Solr instance. The logical next step
is to collect them system-wide and expose the system-wide metrics. Whether
that'd be JMX or not is an open question, but it'd sure make operations people
happy.
So while we're working on this particular issue (which I think is a great idea)
perhaps we can do so with an eye towards exposing both the overall single-solr
instance information and the aggregate information to external consumers.
> Umbrella JIRA for Cluster Management framework in SolrCloud
> ---
>
> Key: SOLR-9735
> URL: https://issues.apache.org/jira/browse/SOLR-9735
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Anshum Gupta
> Original Estimate: 1,344h
> Remaining Estimate: 1,344h
>
> As SolrCloud is now used at fairly large scale, most users end up writing
> their own cluster management tools. We should have a framework for cluster
> management in Solr.
> In a discussion with [~noble.paul], we outlined the following steps w.r.t.
> the approach to having this implemented:
> * *Basic API* calls for cluster management e.g. utilize added nodes, remove a
> node etc. These calls would need explicit invocation by the users to begin
> with. It would also specify the {{strategy}} to use. For instance I can have
> a strategy called {{optimizeCoreCount}} which would target to have an even
> no:of cores in each node . The strategy could optionally take parameters as
> well
> * *Metrics* and stats tracking e.g. qps, etc. These would be required for any
> advanced cluster management tasks e.g. *maintain a qps of 'x'* by
> *auto-adding a replica* (using a recipe) etc. We would need
> collection/shard/node level views of metrics for this.
> * *Recipes*: combination of multiple sequential/parallel API calls based on
> rules. This would be complicated specially as most of these would be long
> running series of tasks which would either have to be rolled back or resumed
> in case of a failure.
> * *Event based triggers* that would not require explicit cluster management
> calls for end users.
--
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-9726) DocValuesFacets: move 'contains' check after 'min' check
[ https://issues.apache.org/jira/browse/SOLR-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke reassigned SOLR-9726: - Assignee: Christine Poerschke > DocValuesFacets: move 'contains' check after 'min' check > > > Key: SOLR-9726 > URL: https://issues.apache.org/jira/browse/SOLR-9726 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jonny Marks >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-9726.patch > > > If a query requests facets with a 'contains' check, DocValuesFacets converts > each term's ordinal to a BytesRef, does the string match and then checks > whether it has a high enough count to go in the priority queue. > This patch moves the lookup after the min check so that we don't do it for > all terms. -- 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-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
[
https://issues.apache.org/jira/browse/LUCENE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644533#comment-15644533
]
Mikhail Khludnev commented on LUCENE-7534:
--
ok. it helped a little. Now it works like:
{code}
.. everything is fine
unpack solr-6.3.0.tgz...
Starting up Solr on port 8983 using command:
C:\cygwin64\tmp\rc3\unpack\solr-6.3.0-java8\bin\solr.cmd start -p 8983 -s
"C:\cygwin64\tmp\rc3\unpack\solr-6.3.0-java8\example\techproducts\solr"
Waiting up to 30 to see Solr running on port 8983
Started Solr server on port 8983. Happy searching!
...
unpack solr-6.3.0.zip...
C:\cygwin64\tmp\rc3\unpack\solr-6.3.0-java8\bin\solr.cmd start -p 8983 -s
"C:\cygwin64\tmp\rc3\unpack\solr-6.3.0-java8\example\techproducts\solr"
Waiting up to 30 to see Solr running on port 8983
Started Solr server on port 8983. Happy searching!
...
unpack solr-6.3.0-src.tgz...
...
Verify...
test solr example w/ Java 8...
start Solr instance (log=/tmp/rc3/unpack/solr-6.3.0/solr-example.log)...
env: ‘bin/solr.cmd’: Permission denied
Running techproducts example on port 8983 from /tmp/rc3/unpack/solr-6.3.0
env: ‘bin/solr.cmd’: Permission denied
stop server using: bin/solr stop -p 8983
env: ‘bin/solr.cmd’: Permission denied
Traceback (most recent call last):
File "dev-tools/scripts/smokeTestRelease.py", line 1447, in
main()
File "dev-tools/scripts/smokeTestRelease.py", line 1391, 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 1437, in smokeTest
gitRevision, version, testArgs, baseURL)
File "dev-tools/scripts/smokeTestRelease.py", line 597, in unpackAndVerify
verifyUnpacked(java, project, artifact, unpackPath, gitRevision, version,
testArgs, tmpDir, baseURL)
File "dev-tools/scripts/smokeTestRelease.py", line 711, in verifyUnpacked
testSolrExample(unpackPath, java.java8_home, True)
File "dev-tools/scripts/smokeTestRelease.py", line 823, in testSolrExample
raise RuntimeError('Failed to run the techproducts example, check log for
previous errors.')
RuntimeError: Failed to run the techproducts example, check log for previous
errors.
{code}
it seems like solr-6.3.0-src.tgz doesn't carry executable attr for solr.cmd, at
contrast to solr-6.3.0.zip, solr-6.3.0.tgz. What's the trick over there? It
should hardly be different for windows? or..
> smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
> Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch,
> LUCENE-7534.patch, fail due to long classpath test.log
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1440, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
> File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
> File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
> File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' %
> java_home).read().decode('utf-8').strip()
> File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
> File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
> File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and
> args should be either supplied as array of terms or supplied as {{shell=True}}
--
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-9659) Add zookeeper DataWatch API
[ https://issues.apache.org/jira/browse/SOLR-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644522#comment-15644522 ] Erick Erickson commented on SOLR-9659: -- Progress not perfection. I was puzzled a bit by the fact that this code is all additions, then saw the line "The follow-up patch is a lot bigger". My vote would be to go ahead and commit this and the follow-up. I can imagine we tailor the API going forward to make switching over to Curator easier "sometime". Meanwhile if we get something that consolidates scattered complex code that's a win. And having the complex code in _one_ place is a big win IMO. > Add zookeeper DataWatch API > --- > > Key: SOLR-9659 > URL: https://issues.apache.org/jira/browse/SOLR-9659 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: SOLR-9659.patch > > > We have several components which need to set up watches on ZooKeeper nodes > for various aspects of cluster management. At the moment, all of these > components do this themselves, leading to large amounts of duplicated code, > and complicated logic for dealing with reconnections, etc, scattered across > the codebase. We should replace this with a simple API controlled by > SolrZkClient, which should make the code more robust, and testing > considerably easier. -- 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-9682) Ability to specify a query with a parameter name (in facet filter)
[ https://issues.apache.org/jira/browse/SOLR-9682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644430#comment-15644430 ] Yonik Seeley commented on SOLR-9682: I considered that, but he long view is that a filter is a list of queries in JSON Query Syntax (there's an old issue open, never got to finish it), and a string is a query in lucene/solr syntax. So for maximum consistency, one would then want to change lucene/solr syntax to accept "$myFilterParam" as well. If not, one would then need to escape queries differently depending on if they will be used in something like "fq" vs "filter". > Ability to specify a query with a parameter name (in facet filter) > -- > > Key: SOLR-9682 > URL: https://issues.apache.org/jira/browse/SOLR-9682 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9682.patch > > > Currently, "filter" only supports query strings (examples at > http://yonik.com/solr-json-request-api/ ) > It would be nice to be able to reference a param that would be parsed as a > lucene/solr query. Multi-valued parameters should be supported. > We should keep in mind (and leave room for) a future "JSON Query Syntax" and > chose labels appropriately. -- 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-9735) Umbrella JIRA for Cluster Management framework in SolrCloud
[
https://issues.apache.org/jira/browse/SOLR-9735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-9735:
-
Description:
As SolrCloud is now used at fairly large scale, most users end up writing their
own cluster management tools. We should have a framework for cluster management
in Solr.
In a discussion with [~noble.paul], we outlined the following steps w.r.t. the
approach to having this implemented:
* *Basic API* calls for cluster management e.g. utilize added nodes, remove a
node etc. These calls would need explicit invocation by the users to begin
with. It would also specify the {{strategy}} to use. For instance I can have a
strategy called {{optimizeCoreCount}} which would target to have an even no:of
cores in each node . The strategy could optionally take parameters as well
* *Metrics* and stats tracking e.g. qps, etc. These would be required for any
advanced cluster management tasks e.g. *maintain a qps of 'x'* by *auto-adding
a replica* (using a recipe) etc. We would need collection/shard/node level
views of metrics for this.
* *Recipes*: combination of multiple sequential/parallel API calls based on
rules. This would be complicated specially as most of these would be long
running series of tasks which would either have to be rolled back or resumed in
case of a failure.
* *Event based triggers* that would not require explicit cluster management
calls for end users.
was:
As SolrCloud is now used at fairly large scale, most users end up writing their
own cluster management tools. We should have a framework for cluster management
in Solr.
In a discussion with [~noble.paul], we outlined the following steps w.r.t. the
approach to having this implemented:
* *Basic API* calls for cluster management e.g. utilize added nodes, remove a
node etc. These calls would need explicit invocation by the users to begin with.
* *Metrics* and stats tracking e.g. qps, etc. These would be required for any
advanced cluster management tasks e.g. *maintain a qps of 'x'* by *auto-adding
a replica* (using a recipe) etc. We would need collection/shard/node level
views of metrics for this.
* *Recipes*: combination of multiple sequential/parallel API calls based on
rules. This would be complicated specially as most of these would be long
running series of tasks which would either have to be rolled back or resumed in
case of a failure.
* *Event based triggers* that would not require explicit cluster management
calls for end users.
> Umbrella JIRA for Cluster Management framework in SolrCloud
> ---
>
> Key: SOLR-9735
> URL: https://issues.apache.org/jira/browse/SOLR-9735
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Anshum Gupta
> Original Estimate: 1,344h
> Remaining Estimate: 1,344h
>
> As SolrCloud is now used at fairly large scale, most users end up writing
> their own cluster management tools. We should have a framework for cluster
> management in Solr.
> In a discussion with [~noble.paul], we outlined the following steps w.r.t.
> the approach to having this implemented:
> * *Basic API* calls for cluster management e.g. utilize added nodes, remove a
> node etc. These calls would need explicit invocation by the users to begin
> with. It would also specify the {{strategy}} to use. For instance I can have
> a strategy called {{optimizeCoreCount}} which would target to have an even
> no:of cores in each node . The strategy could optionally take parameters as
> well
> * *Metrics* and stats tracking e.g. qps, etc. These would be required for any
> advanced cluster management tasks e.g. *maintain a qps of 'x'* by
> *auto-adding a replica* (using a recipe) etc. We would need
> collection/shard/node level views of metrics for this.
> * *Recipes*: combination of multiple sequential/parallel API calls based on
> rules. This would be complicated specially as most of these would be long
> running series of tasks which would either have to be rolled back or resumed
> in case of a failure.
> * *Event based triggers* that would not require explicit cluster management
> calls for end users.
--
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-9490) BoolField always returning false for non-DV fields when javabin involved (via solrj, or intra node communication)
[
https://issues.apache.org/jira/browse/SOLR-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644382#comment-15644382
]
Tim Owen commented on SOLR-9490:
Just to add to this, if anyone was using 6.2.0 and doing document updates, this
bug affected Atomic Updates and will have reset all boolean fields in the
document to false when updating other fields of the document i.e. the
actually-stored and indexed values are changed. We discovered this just
recently and noticed some documents had lost their original boolean value,
because we had been doing Atomic updates during the period we were running
6.2.0 and that had reset the values in the document itself. Even though we've
now upgraded to 6.2.1 so the displayed values are shown correctly, the stored
values have now been changed.
> BoolField always returning false for non-DV fields when javabin involved (via
> solrj, or intra node communication)
> -
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.2
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Critical
> Fix For: 6.2.1, 6.3, master (7.0)
>
> Attachments: SOLR-9490.patch, SOLR-9490.patch, Solr9490.java
>
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in
> BoolField now means that booleans without DocValues return null, which then
> turns into Boolean.FALSE in toObject() regardless of whether the value is
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are
> wrong.
> {code}
> required="false" multiValued="false"/>
>
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
> {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
> },
> "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
> "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
> return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and
> installed my core.
> In my schema.xml i have an field like following :
> multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting
> false value for above field even though it contains true boolean value. This
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin&version=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So
> clearly this is a bug in version 6.2.0.
> {quote}
--
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-9682) Ability to specify a query with a parameter name (in facet filter)
[
https://issues.apache.org/jira/browse/SOLR-9682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644374#comment-15644374
]
David Smiley commented on SOLR-9682:
What about {{filter : "$myFilterParam"}} -- thus have certain value resolution
support dollar sign references, consistent with local-params? That way we
needn't make some parameters support structured values unnecessarily, requiring
more names (i.e. "param").
> Ability to specify a query with a parameter name (in facet filter)
> --
>
> Key: SOLR-9682
> URL: https://issues.apache.org/jira/browse/SOLR-9682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Yonik Seeley
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9682.patch
>
>
> Currently, "filter" only supports query strings (examples at
> http://yonik.com/solr-json-request-api/ )
> It would be nice to be able to reference a param that would be parsed as a
> lucene/solr query. Multi-valued parameters should be supported.
> We should keep in mind (and leave room for) a future "JSON Query Syntax" and
> chose labels appropriately.
--
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] [Comment Edited] (SOLR-9127) XLSX response writer - do we want it?
[
https://issues.apache.org/jira/browse/SOLR-9127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644363#comment-15644363
]
Noble Paul edited comment on SOLR-9127 at 11/7/16 2:44 PM:
---
It requires all of {{extraction/lib/*.jar}} and {{dist/solr-cell-6.3.0.jar}}
in the server classpath. it's not enough to have it in the core classpath.
was (Author: noble.paul):
It requires all of {{extraction/lib/*.jar}} and {{dist/solr-cell-6.3.0.jar}}
in the server classpath
> XLSX response writer - do we want it?
> -
>
> Key: SOLR-9127
> URL: https://issues.apache.org/jira/browse/SOLR-9127
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
>Reporter: Tony Moriarty
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.3
>
> Attachments: 9127-xlsxresponsewriter.patch, SOLR-9127.patch
>
>
> I recently open sourced an XLSX response writer based on solr 4.6 and apache
> poi.
> https://github.com/desultir/SolrXLSXResponseWriter
> Is this something the community would be interested in bringing into the solr
> codebase? I'm willing to put the work into porting it to solr5 and solr6 if
> the community is interested, happy to leave it as a plugin otherwise.
--
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-9127) XLSX response writer - do we want it?
[
https://issues.apache.org/jira/browse/SOLR-9127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644363#comment-15644363
]
Noble Paul commented on SOLR-9127:
--
It requires all of {{extraction/lib/*.jar}} and {{dist/solr-cell-6.3.0.jar}}
in the server classpath
> XLSX response writer - do we want it?
> -
>
> Key: SOLR-9127
> URL: https://issues.apache.org/jira/browse/SOLR-9127
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
>Reporter: Tony Moriarty
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.3
>
> Attachments: 9127-xlsxresponsewriter.patch, SOLR-9127.patch
>
>
> I recently open sourced an XLSX response writer based on solr 4.6 and apache
> poi.
> https://github.com/desultir/SolrXLSXResponseWriter
> Is this something the community would be interested in bringing into the solr
> codebase? I'm willing to put the work into porting it to solr5 and solr6 if
> the community is interested, happy to leave it as a plugin otherwise.
--
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-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-9293: -- Fix Version/s: 6.4 > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0), 6.4 > > -- 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-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-9293: -- Fix Version/s: (was: 6x) > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0), 6.4 > > -- 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-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-9293. --- Resolution: Fixed > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0), 6.4 > > -- 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-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644325#comment-15644325 ] ASF subversion and git services commented on SOLR-9293: --- Commit 7fb72bfe10d84d3419b07a8782418f86ab075a56 in lucene-solr's branch refs/heads/master from [~dawid.weiss] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7fb72bf ] SOLR-9293: Solrj client support for hierarchical clusters and other topics marker. > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0), 6x > > -- 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-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-9293: -- Fix Version/s: 6x > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0), 6x > > -- 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-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644324#comment-15644324 ] ASF subversion and git services commented on SOLR-9293: --- Commit fb83d64eac0a88e7a78e74b713da090c63c1daad in lucene-solr's branch refs/heads/branch_6x from [~dawid.weiss] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fb83d64 ] SOLR-9293: Solrj client support for hierarchical clusters and other topics marker. > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0), 6x > > -- 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-8897) SSL-related passwords in solr.in.sh are in plain text
[ https://issues.apache.org/jira/browse/SOLR-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644273#comment-15644273 ] Marcel Berteler commented on SOLR-8897: --- A slightly better way than using clear txt is using the obfuscated (OBF) version of the password which can be generated using the password utility that comes with Jetty. http://wiki.eclipse.org/Jetty/Howto/Secure_Passwords > SSL-related passwords in solr.in.sh are in plain text > - > > Key: SOLR-8897 > URL: https://issues.apache.org/jira/browse/SOLR-8897 > Project: Solr > Issue Type: Improvement > Components: scripts and tools, security >Reporter: Esther Quansah > > As per the steps mentioned at following URL, one needs to store the plain > text password for the keystore to configure SSL for Solr, which is not a good > idea from security perspective. > URL: > https://cwiki.apache.org/confluence/display/solr/Enabling+SSL#EnablingSSL-SetcommonSSLrelatedsystemproperties > > (https://cwiki.apache.org/confluence/display/solr/Enabling+SSL#EnablingSSL-SetcommonSSLrelatedsystemproperties) > Is there any way so that the encrypted password can be stored (instead of > plain password) in solr.in.cmd/solr.in.sh to configure SSL? -- 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-8491) solr.cmd SOLR_SSL_OPTS is overwritten
[
https://issues.apache.org/jira/browse/SOLR-8491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644255#comment-15644255
]
Marcel Berteler commented on SOLR-8491:
---
@sam Yi already mentioned the fix:
line 49 and 51: change
{code:xml}
%SOLR_SSL_OPTS%
{code}
to
{code:xml}
!SOLR_SSL_OPTS!
{code}
Can this please be fixed? Without applying this fix, the only way to get SSL to
work is by editing the xml files in the etc folder, which is clearly not the
best solution.
> solr.cmd SOLR_SSL_OPTS is overwritten
> -
>
> Key: SOLR-8491
> URL: https://issues.apache.org/jira/browse/SOLR-8491
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Affects Versions: 5.2, 6.0
> Environment: Windows
>Reporter: Sam Yi
>
> In solr.cmd, the SOLR_SSL_OPTS variable is assigned within a block, but then
> assigned again later in the same block, using {{%SOLR_SSL_OPTS%}} to attempt
> to append to itself. However, since we're still inside the same block for
> this 2nd assignment, {{%SOLR_SSL_OPTS%}} resolves to nothing, so everything
> in the first assignment (the solr.jetty opts) becomes overwritten.
> I was able to work around this by using {code}!SOLR_SSL_OPTS!{code} instead
> of {{%SOLR_SSL_OPTS%}} in the 2nd assignments (in both the {{IF}} and
> {{ELSE}} blocks), since delayed expension is enabled.
> Here's the full block for reference, from commit
> d4e3f50a6f6bc7b96fa6317f028ae26be25c8928, lines 43-55:
> {code}IF DEFINED SOLR_SSL_KEY_STORE (
> set "SOLR_JETTY_CONFIG=--module=https"
> set SOLR_URL_SCHEME=https
> set "SCRIPT_ERROR=Solr server directory %SOLR_SERVER_DIR% not found!"
> set "SOLR_SSL_OPTS=-Dsolr.jetty.keystore=%SOLR_SSL_KEY_STORE%
> -Dsolr.jetty.keystore.password=%SOLR_SSL_KEY_STORE_PASSWORD%
> -Dsolr.jetty.truststore=%SOLR_SSL_TRUST_STORE%
> -Dsolr.jetty.truststore.password=%SOLR_SSL_TRUST_STORE_PASSWORD%
> -Dsolr.jetty.ssl.needClientAuth=%SOLR_SSL_NEED_CLIENT_AUTH%
> -Dsolr.jetty.ssl.wantClientAuth=%SOLR_SSL_WANT_CLIENT_AUTH%"
> IF DEFINED SOLR_SSL_CLIENT_KEY_STORE (
> set "SOLR_SSL_OPTS=%SOLR_SSL_OPTS%
> -Djavax.net.ssl.keyStore=%SOLR_SSL_CLIENT_KEY_STORE%
> -Djavax.net.ssl.keyStorePassword=%SOLR_SSL_CLIENT_KEY_STORE_PASSWORD%
> -Djavax.net.ssl.trustStore=%SOLR_SSL_CLIENT_TRUST_STORE%
> -Djavax.net.ssl.trustStorePassword=%SOLR_SSL_CLIENT_TRUST_STORE_PASSWORD%"
> ) ELSE (
> set "SOLR_SSL_OPTS=%SOLR_SSL_OPTS%
> -Djavax.net.ssl.keyStore=%SOLR_SSL_KEY_STORE%
> -Djavax.net.ssl.keyStorePassword=%SOLR_SSL_KEY_STORE_PASSWORD%
> -Djavax.net.ssl.trustStore=%SOLR_SSL_TRUST_STORE%
> -Djavax.net.ssl.trustStorePassword=%SOLR_SSL_TRUST_STORE_PASSWORD%"
> )
> ) ELSE (
> set SOLR_SSL_OPTS=
> )
> {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] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
[
https://issues.apache.org/jira/browse/LUCENE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644246#comment-15644246
]
Dawid Weiss commented on LUCENE-7534:
-
No problem at all.
> smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
> Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch,
> LUCENE-7534.patch, fail due to long classpath test.log
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1440, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
> File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
> File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
> File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' %
> java_home).read().decode('utf-8').strip()
> File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
> File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
> File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and
> args should be either supplied as array of terms or supplied as {{shell=True}}
--
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-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
[
https://issues.apache.org/jira/browse/LUCENE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644243#comment-15644243
]
Mikhail Khludnev commented on LUCENE-7534:
--
I respin it again passing a short {{--tmp-dir}}, obviously... sorry for
bothering you.
> smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
> Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch,
> LUCENE-7534.patch, fail due to long classpath test.log
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1440, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
> File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
> File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
> File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' %
> java_home).read().decode('utf-8').strip()
> File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
> File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
> File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and
> args should be either supplied as array of terms or supplied as {{shell=True}}
--
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-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
[
https://issues.apache.org/jira/browse/LUCENE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644230#comment-15644230
]
Dawid Weiss commented on LUCENE-7534:
-
Btw. there is a way to pass arguments to "java" bootstrap via an external file,
but this is only available from 9+. See this JEP:
http://openjdk.java.net/jeps/293
> smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
> Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch,
> LUCENE-7534.patch, fail due to long classpath test.log
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1440, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
> File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
> File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
> File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' %
> java_home).read().decode('utf-8').strip()
> File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
> File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
> File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and
> args should be either supplied as array of terms or supplied as {{shell=True}}
--
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-9293) Solrj client support for hierarchical clusters and other topics marker
[ https://issues.apache.org/jira/browse/SOLR-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-9293: -- Summary: Solrj client support for hierarchical clusters and other topics marker (was: Solrj client should support and parse hierarchical clusters) > Solrj client support for hierarchical clusters and other topics marker > -- > > Key: SOLR-9293 > URL: https://issues.apache.org/jira/browse/SOLR-9293 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (7.0) > > -- 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-9727) solr.in.sh properties does not set the correct values.
[
https://issues.apache.org/jira/browse/SOLR-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644137#comment-15644137
]
Michael Suzuki commented on SOLR-9727:
--
The issue is that the property does not get set in jetty when its {code}
solr.jetty.ssl.needClientAuth {code}
If you repeat the steps mentioned above and debug it, you will see that its
always false unless its all lower case.
> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Michael Suzuki
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false.
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.
--
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-9727) solr.in.sh properties does not set the correct values.
[
https://issues.apache.org/jira/browse/SOLR-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Suzuki updated SOLR-9727:
-
Affects Version/s: (was: 6.3)
master (7.0)
> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Michael Suzuki
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false.
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.
--
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-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
[
https://issues.apache.org/jira/browse/LUCENE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644019#comment-15644019
]
Dawid Weiss commented on LUCENE-7534:
-
Paths added via -D are passed verbatim from ant's buildfile, the runner has
nothing to do with it (so are classpath entries, actually).
You could modify it to use relative paths, but verbosity here will save you
days in debugging should something go wrong and there are classpath lookup
issues somewhere... Absolute classpaths also permit low-level rerunning of the
same "java" command used to fork the process, which again is very handy for
debugging.
bq. smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4
You could change this part to use short git rev (again -- this is in the smoke
tester/ build files).
bq. Can't it use jar folders, or switch paths to relative ones?
What are JAR folders? If you mean overriding ext dirs property, then no, it's
different class loader and runtime behavior. If you mean a synthetic JAR with
manifest entries then, again, no -- this would be different from a vanilla
{{--cp}} run and the runner shouldn't alter the default behavior here.
> smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
> Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch,
> LUCENE-7534.patch, fail due to long classpath test.log
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1440, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
> File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
> File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
> File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' %
> java_home).read().decode('utf-8').strip()
> File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
> File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
> File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and
> args should be either supplied as array of terms or supplied as {{shell=True}}
--
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-9728) Ability to specify Key Store type in solr.in file for SSL
[
https://issues.apache.org/jira/browse/SOLR-9728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Suzuki updated SOLR-9728:
-
Attachment: SOLR-9728.patch
> Ability to specify Key Store type in solr.in file for SSL
> -
>
> Key: SOLR-9728
> URL: https://issues.apache.org/jira/browse/SOLR-9728
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Michael Suzuki
> Attachments: SOLR-9728.patch
>
>
> At present when ssl is enabled we can't set the SSL type. It currently
> defaults to JCK.
> As a user I would like to configure the SSL type via the solr.in file.
> For instance "JCEKS" would be configured as:
> {code}
> SOLR_SSL_KEYSTORE_TYPE=JCEKS
> SOLR_SSL_TRUSTSTORE_TYPE=JCEKS
> {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-9727) solr.in.sh properties does not set the correct values.
[
https://issues.apache.org/jira/browse/SOLR-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644001#comment-15644001
]
Jan Høydahl commented on SOLR-9727:
---
Skimming your patch, I don't see the point in renaming the Java Property
everywhere? Why should there be a problem using camel-case in
{{solr.jetty.ssl.needClientAuth}}, as long as it is consistent between the
start script and {{jetty-ssl.xml}}.
Also you list 6.3 as affects version, but that version is not released. Did you
mean 5.3?
> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 6.3
>Reporter: Michael Suzuki
>Assignee: Michael Suzuki
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false.
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.
--
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-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18226 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18226/
Java: 32bit/jdk-9-ea+140 -client -XX:+UseParallelGC
1 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest
Error Message:
1 thread leaked from SUITE scope at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 1) Thread[id=5086,
name=OverseerHdfsCoreFailoverThread-96896097677672458-127.0.0.1:44015_solr-n_03,
state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at
java.lang.Thread.sleep(java.base@9-ea/Native Method) at
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE
scope at org.apache.solr.cloud.CollectionsAPIDistributedZkTest:
1) Thread[id=5086,
name=OverseerHdfsCoreFailoverThread-96896097677672458-127.0.0.1:44015_solr-n_03,
state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.]
at java.lang.Thread.sleep(java.base@9-ea/Native Method)
at
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
at __randomizedtesting.SeedInfo.seed([EF734053447575D6]:0)
Build Log:
[...truncated 11437 lines...]
[junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
[junit4] 2> Creating dataDir:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.CollectionsAPIDistributedZkTest_EF734053447575D6-001/init-core-data-001
[junit4] 2> 660367 INFO
(SUITE-CollectionsAPIDistributedZkTest-seed#[EF734053447575D6]-worker) []
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via:
@org.apache.solr.util.RandomizeSSL(reason="", ssl=0.0/0.0, value=0.0/0.0,
clientAuth=0.0/0.0)
[junit4] 2> 660370 INFO
(SUITE-CollectionsAPIDistributedZkTest-seed#[EF734053447575D6]-worker) []
o.a.s.c.MiniSolrCloudCluster Starting cluster of 4 servers in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.CollectionsAPIDistributedZkTest_EF734053447575D6-001/tempDir-001
[junit4] 2> 660370 INFO
(SUITE-CollectionsAPIDistributedZkTest-seed#[EF734053447575D6]-worker) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 660370 INFO (Thread-1151) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 660371 INFO (Thread-1151) [] o.a.s.c.ZkTestServer
Starting server
[junit4] 2> 660471 INFO
(SUITE-CollectionsAPIDistributedZkTest-seed#[EF734053447575D6]-worker) []
o.a.s.c.ZkTestServer start zk server on port:45207
[junit4] 2> 660480 INFO (jetty-launcher-828-thread-3) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 660480 INFO (jetty-launcher-828-thread-2) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 660480 INFO (jetty-launcher-828-thread-4) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 660480 INFO (jetty-launcher-828-thread-1) []
o.e.j.s.Server jetty-9.3.8.v20160314
[junit4] 2> 660481 INFO (jetty-launcher-828-thread-4) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@448eed{/solr,null,AVAILABLE}
[junit4] 2> 660482 INFO (jetty-launcher-828-thread-2) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@98bc33{/solr,null,AVAILABLE}
[junit4] 2> 660482 INFO (jetty-launcher-828-thread-4) []
o.e.j.s.ServerConnector Started ServerConnector@2f883a{SSL,[ssl,
http/1.1]}{127.0.0.1:38755}
[junit4] 2> 660482 INFO (jetty-launcher-828-thread-4) []
o.e.j.s.Server Started @662071ms
[junit4] 2> 660482 INFO (jetty-launcher-828-thread-4) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=38755}
[junit4] 2> 660482 ERROR (jetty-launcher-828-thread-4) []
o.a.s.s.StartupLoggingUtils Missing Java Option solr.log.dir. Logging may be
missing or incomplete.
[junit4] 2> 660482 INFO (jetty-launcher-828-thread-4) []
o.a.s.s.SolrDispatchFilter ___ _ Welcome to Apache Solr? version
7.0.0
[junit4] 2> 660482 INFO (jetty-launcher-828-thread-4) []
o.a.s.s.SolrDispatchFilter / __| ___| |_ _ Starting in cloud mode on port null
[junit4] 2> 660482 INFO (jetty-launcher-828-thread-4) []
o.a.s.s.SolrDispatchFilter \__ \/ _ \ | '_| Install dir: null
[junit4] 2> 660482 INFO (jetty-launcher-828-thread-4) []
o.a.s.s.SolrDispatchFilter |___/\___/_|_|Start time:
2016-11-07T11:11:55.552918Z
[junit4] 2> 660484 INFO (jetty-launcher-828-thread-2) []
o.e.j.s.ServerConnector Started ServerConnector@14ff833{SSL,[ssl,
http/1.1]}{127.0.0.1:44015}
[junit4] 2> 660484 INFO (jetty-launcher-828-thread-3) []
o.e
[jira] [Updated] (SOLR-9728) Ability to specify Key Store type in solr.in file for SSL
[
https://issues.apache.org/jira/browse/SOLR-9728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Suzuki updated SOLR-9728:
-
Description:
At present when ssl is enabled we can't set the SSL type. It currently defaults
to JCK.
As a user I would like to configure the SSL type via the solr.in file.
For instance "JCEKS" would be configured as:
{code}
SOLR_SSL_KEYSTORE_TYPE=JCEKS
SOLR_SSL_TRUSTSTORE_TYPE=JCEKS
{code}
was:
At present when ssl is enabled we can't set the SSL type. It currently defaults
to JCK.
As a user I would like to configure the SSL type via the solr.in file.
For instance "JCEKS" would be configured as:
{code}
SOLR_SSL_KEY_TYPE=JCEKS
{code}
> Ability to specify Key Store type in solr.in file for SSL
> -
>
> Key: SOLR-9728
> URL: https://issues.apache.org/jira/browse/SOLR-9728
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Michael Suzuki
>
> At present when ssl is enabled we can't set the SSL type. It currently
> defaults to JCK.
> As a user I would like to configure the SSL type via the solr.in file.
> For instance "JCEKS" would be configured as:
> {code}
> SOLR_SSL_KEYSTORE_TYPE=JCEKS
> SOLR_SSL_TRUSTSTORE_TYPE=JCEKS
> {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] [Comment Edited] (SOLR-9727) solr.in.sh properties does not set the correct values.
[
https://issues.apache.org/jira/browse/SOLR-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636013#comment-15636013
]
Michael Suzuki edited comment on SOLR-9727 at 11/7/16 11:29 AM:
The jetty-ssl.xml does not define the properties correctly, the property name
should not be camel cased.
{code}
{code}
was (Author: michaelsuzuki):
The jetty-ssl.xml do not define the properties correctly, the property name
should not be camel cased.
{code}
{code}
> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 6.3
>Reporter: Michael Suzuki
>Assignee: Michael Suzuki
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false.
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.
--
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-9728) Ability to specify Key Store type in solr.in file for SSL
[
https://issues.apache.org/jira/browse/SOLR-9728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Suzuki updated SOLR-9728:
-
Description:
At present when ssl is enabled we can't set the SSL type. It currently defaults
to JCK.
As a user I would like to configure the SSL type via the solr.in file.
For instance "JCEKS" would be configured as:
{code}
SOLR_SSL_KEY_TYPE=JCEKS
{code}
was:At present when ssl is enabled we can't set the SSL type. It currently
defaults to JCK, as a user it would be helpful to have this as a property that
can set the required SSL type, for instance "JCEKS".
> Ability to specify Key Store type in solr.in file for SSL
> -
>
> Key: SOLR-9728
> URL: https://issues.apache.org/jira/browse/SOLR-9728
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Michael Suzuki
>
> At present when ssl is enabled we can't set the SSL type. It currently
> defaults to JCK.
> As a user I would like to configure the SSL type via the solr.in file.
> For instance "JCEKS" would be configured as:
> {code}
> SOLR_SSL_KEY_TYPE=JCEKS
> {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-9659) Add zookeeper DataWatch API
[ https://issues.apache.org/jira/browse/SOLR-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643903#comment-15643903 ] Alan Woodward commented on SOLR-9659: - bq. this patch adds a significant amount of new code to Solr It's not that big, is it? The follow-up patch is a lot bigger, but that's mainly removing code that already does what this does, only duplicated in multiple places, and wrong in a couple of them. If people are really against this, then I'll close the ticket. But I think it's a significant improvement, and I don't see any other ways of doing this incrementally. > Add zookeeper DataWatch API > --- > > Key: SOLR-9659 > URL: https://issues.apache.org/jira/browse/SOLR-9659 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: SOLR-9659.patch > > > We have several components which need to set up watches on ZooKeeper nodes > for various aspects of cluster management. At the moment, all of these > components do this themselves, leading to large amounts of duplicated code, > and complicated logic for dealing with reconnections, etc, scattered across > the codebase. We should replace this with a simple API controlled by > SolrZkClient, which should make the code more robust, and testing > considerably easier. -- 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] [Comment Edited] (SOLR-8998) JSON Facet API child roll-ups
[ https://issues.apache.org/jira/browse/SOLR-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643879#comment-15643879 ] Mikhail Khludnev edited comment on SOLR-8998 at 11/7/16 11:11 AM: -- [~Eng1neer], # I think this is the only one. # I don't know how it will end up in SOLR-9510, but [so far|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15622209&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15622209] it expose a room for performance improvement, imho. was (Author: mkhludnev): [~Eng1neer], # I think this is the only one. # I don't know how it will end up in SOLR-9501, but [so far|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15622209&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15622209] it expose a room for performance improvement, imho. > JSON Facet API child roll-ups > - > > Key: SOLR-8998 > URL: https://issues.apache.org/jira/browse/SOLR-8998 > Project: Solr > Issue Type: New Feature > Components: Facet Module >Reporter: Yonik Seeley > > The JSON Facet API currently has the ability to map between parents and > children ( see http://yonik.com/solr-nested-objects/ ) > This issue is about adding a true rollup ability where parents would take on > derived values from their children. The most important part (and the most > difficult part) will be the external API. -- 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-8998) JSON Facet API child roll-ups
[ https://issues.apache.org/jira/browse/SOLR-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643879#comment-15643879 ] Mikhail Khludnev commented on SOLR-8998: [~Eng1neer], # I think this is the only one. # I don't know how it will end up in SOLR-9501, but [so far|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15622209&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15622209] it expose a room for performance improvement, imho. > JSON Facet API child roll-ups > - > > Key: SOLR-8998 > URL: https://issues.apache.org/jira/browse/SOLR-8998 > Project: Solr > Issue Type: New Feature > Components: Facet Module >Reporter: Yonik Seeley > > The JSON Facet API currently has the ability to map between parents and > children ( see http://yonik.com/solr-nested-objects/ ) > This issue is about adding a true rollup ability where parents would take on > derived values from their children. The most important part (and the most > difficult part) will be the external API. -- 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-9727) solr.in.sh properties does not set the correct values.
[
https://issues.apache.org/jira/browse/SOLR-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643878#comment-15643878
]
Michael Suzuki commented on SOLR-9727:
--
[~timporter] please let me know if the above patch is sufficient?
If we need to add tests how and what would you recommend?
> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 6.3
>Reporter: Michael Suzuki
>Assignee: Michael Suzuki
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false.
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.
--
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 # 1464 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1464/ 1 tests failed. FAILED: org.apache.solr.cloud.TestRandomRequestDistribution.test Error Message: Shard a1x2_shard1_replica1 received all 10 requests Stack Trace: java.lang.AssertionError: Shard a1x2_shard1_replica1 received all 10 requests at __randomizedtesting.SeedInfo.seed([96EF7A0802B170BE:1EBB45D2AC4D1D46]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:122) at org.apache.solr.cloud.TestRandomRequestDistribution.test(TestRandomRequestDistribution.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl
[jira] [Commented] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
[
https://issues.apache.org/jira/browse/LUCENE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643861#comment-15643861
]
Mikhail Khludnev commented on LUCENE-7534:
--
[~dawid.weiss], is there a way to shorten slave command line and/or classpath?
Can't it use jar folders, or switch paths to relative ones?
{quote}
[junit4] Caused by: java.io.IOException: CreateProcess error=206, The
filename or extension is too long
[junit4] at java.lang.ProcessImpl.create(Native Method)
[junit4] at java.lang.ProcessImpl.(ProcessImpl.java:386)
[junit4] at java.lang.ProcessImpl.start(ProcessImpl.java:137)
[junit4] at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
[junit4] ... 13 more
[junit4] ERROR: JVM J2 ended with an exception, command line: "C:\Program
Files\Java\jdk1.8.0_102\jre\bin\java.exe" -ea -esa -Dtests.prefix=tests
-Dtests.seed=5AA2B74D3487DDFB -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=6.3.0 -Dtests.cleanthreads=perClass
-Djava.util.logging.config.file=C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\lucene\tools\junit4\logging.properties
-Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false
-Dtests.slow=false -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp
-Djava.io.tmpdir=./temp
-Djunit4.tempDir=C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\solr\build\contrib\solr-map-reduce\test\temp
-Dcommon.dir=C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\lucene
-Dclover.db.dir=C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\lucene\build\clover\db
-Djava.security.policy=C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\lucene\tools\junit4\solr-tests.policy
-Dtests.LUCENE_VERSION=6.3.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:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\solr\build\contrib\solr-map-reduce\test\J2
-Djunit4.childvm.id=2 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false
-Dtests.filterstacks=true -Dtests.disableHdfs=true
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager
-Dfile.encoding=ISO-8859-1 -classpath
"C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\solr\build\contrib\solr-map-reduce\classes\test;C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\solr\build\solr-test-framework\classes\java;C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\solr\test-framework\lib\junit4-ant-2.4.0.jar;C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\solr\contrib\map-reduce\src\test-files;C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\lucene\build\test-framework\classes\java;C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\lucene\build\codecs\classes\java;C:\cygwin64\tmp\smoke_lucene_6.3.0_a66a44513ee8191e25b477372094bfa846450316_4\unpack\solr-6.3.0\solr\build\solr-solrj\classes\java;C:\cygwin64..
{qoute}
> smokeTestRelease.py on cygwin [Errno 2] No such file or directory:
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
> Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch,
> LUCENE-7534.patch, fail due to long classpath test.log
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
> File "dev-tools/scripts/smokeTestRelease.py", line 1440, in
> main()
> File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
> File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
>
[jira] [Updated] (LUCENE-7541) FVH does not work well with phrases and multiple tags
[
https://issues.apache.org/jira/browse/LUCENE-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Pilato updated LUCENE-7541:
-
Description:
I'm indexing a document with a field which is {{aaa bbb ccc ddd bbb eee fff}}.
I'm running a Bool Query which contains 2 should Phrase queries: {{aaa bbb}}
and {{eee fff}}.
I'm using an FVH with two tags {{<1>}} and {{<2>}}.
It gives the correct result: {{<1>aaa bbb ccc ddd bbb <2>eee fff}}
With same settings, I'm now running with 2 should Phrase queries: {{aaa bbb}}
and {{bbb eee}}.
I'm getting back a wrong result: {{<1>aaa bbb ccc ddd <1>bbb eee fff}}
where I'm expecting {{<1>aaa bbb ccc ddd <2>bbb eee fff}}.
Why this?
Apparently the FVH is getting back as sequence numbers in the first case {{0}}
and {{1}} but in the second case {{0}} and {{2}}.
The problem is when we call then {{getPreTag}}, we are getting the first tag
instead of the second one:
{code:java}
protected String getPreTag( String[] preTags, int num ){
int n = num % preTags.length;
return preTags[n];
}
protected String getPostTag( String[] postTags, int num ){
int n = num % postTags.length;
return postTags[n];
}
{code}
I did not find yet how to fix that. But I believe it is somewhere in
{{org.apache.lucene.search.vectorhighlight.FieldQuery}} class
{code:java}
private void markTerminal( int slop, float boost ){
this.terminal = true;
this.slop = slop;
this.boost = boost;
this.termOrPhraseNumber = fieldQuery.nextTermOrPhraseNumber();
}
{code}
This call to {{nextTermOrPhraseNumber()}} increments the term number I guess
because we have already seen the term {{BBB}} previously.
I'm going to join a test case patch.
was:
I'm indexing a document with a field which is {{aaa bbb ccc ddd bbb eee fff}}.
I'm running a Bool Query which contains 2 should Phrase queries: {{aaa bbb}}
and {{eee fff}}.
I'm using an FVH with two tags {{<1>}} and {{<2>}}.
It gives the correct result: {{<1>aaa bbb ccc ddd bbb <2>eee fff}}
With same settings, I'm now running with 2 should Phrase queries: {{aaa bbb}}
and {{bbb eee}}.
I'm getting back a wrong result: {{<1>aaa bbb ccc ddd <1>bbb eee fff}}
where I'm expecting {{<1>aaa bbb ccc ddd <2>bbb eee fff}}.
Why this?
Apparently the FVH is getting back as sequence numbers in the first case {{0}}
and {{1}} but in the second case {{0}} and {{2}}.
The problem is when we call then {{getPreTag}}, we are getting the first tag
instead of the second one:
{code:java}
protected String getPreTag( String[] preTags, int num ){
int n = num % preTags.length;
return preTags[n];
}
protected String getPostTag( String[] postTags, int num ){
int n = num % postTags.length;
return postTags[n];
}
{code:java}
I did not find yet how to fix that. But I believe it is somewhere in
{{org.apache.lucene.search.vectorhighlight.FieldQuery}} class
{code:java}
private void markTerminal( int slop, float boost ){
this.terminal = true;
this.slop = slop;
this.boost = boost;
this.termOrPhraseNumber = fieldQuery.nextTermOrPhraseNumber();
}
{code:java}
This call to {{nextTermOrPhraseNumber()}} increments the term number I guess
because we have already seen the term {{BBB}} previously.
I'm going to join a test case patch.
> FVH does not work well with phrases and multiple tags
> -
>
> Key: LUCENE-7541
> URL: https://issues.apache.org/jira/browse/LUCENE-7541
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/highlighter
>Affects Versions: trunk, 6.x
>Reporter: David Pilato
> Attachments: Add_test_for_FVH_with_phrase_and_multiple_tags_.patch
>
>
> I'm indexing a document with a field which is {{aaa bbb ccc ddd bbb eee fff}}.
> I'm running a Bool Query which contains 2 should Phrase queries: {{aaa bbb}}
> and {{eee fff}}.
> I'm using an FVH with two tags {{<1>}} and {{<2>}}.
> It gives the correct result: {{<1>aaa bbb ccc ddd bbb <2>eee fff}}
> With same settings, I'm now running with 2 should Phrase queries: {{aaa bbb}}
> and {{bbb eee}}.
> I'm getting back a wrong result: {{<1>aaa bbb ccc ddd <1>bbb eee
> fff}} where I'm expecting {{<1>aaa bbb ccc ddd <2>bbb eee fff}}.
> Why this?
> Apparently the FVH is getting back as sequence numbers in the first case
> {{0}} and {{1}} but in the second case {{0}} and {{2}}.
> The problem is when we call then {{getPreTag}}, we are getting the first tag
> instead of the second one:
> {code:java}
> protected String getPreTag( String[] preTags, int num ){
> int n = num % preTags.length;
> return preTags[n];
> }
>
> protected String getPostTag( String[] postTags, int num ){
> int n = num % postTags.length;
> return postTags[n];
> }
> {code}
> I did not find yet how to fix that. But I bel
[jira] [Updated] (LUCENE-7541) FVH does not work well with phrases and multiple tags
[
https://issues.apache.org/jira/browse/LUCENE-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Pilato updated LUCENE-7541:
-
Description:
I'm indexing a document with a field which is {{aaa bbb ccc ddd bbb eee fff}}.
I'm running a Bool Query which contains 2 should Phrase queries: {{aaa bbb}}
and {{eee fff}}.
I'm using an FVH with two tags {{<1>}} and {{<2>}}.
It gives the correct result: {{<1>aaa bbb ccc ddd bbb <2>eee fff}}
With same settings, I'm now running with 2 should Phrase queries: {{aaa bbb}}
and {{bbb eee}}.
I'm getting back a wrong result: {{<1>aaa bbb ccc ddd <1>bbb eee fff}}
where I'm expecting {{<1>aaa bbb ccc ddd <2>bbb eee fff}}.
Why this?
Apparently the FVH is getting back as sequence numbers in the first case {{0}}
and {{1}} but in the second case {{0}} and {{2}}.
The problem is when we call then {{getPreTag}}, we are getting the first tag
instead of the second one:
{code:java}
protected String getPreTag( String[] preTags, int num ){
int n = num % preTags.length;
return preTags[n];
}
protected String getPostTag( String[] postTags, int num ){
int n = num % postTags.length;
return postTags[n];
}
{code:java}
I did not find yet how to fix that. But I believe it is somewhere in
{{org.apache.lucene.search.vectorhighlight.FieldQuery}} class
{code:java}
private void markTerminal( int slop, float boost ){
this.terminal = true;
this.slop = slop;
this.boost = boost;
this.termOrPhraseNumber = fieldQuery.nextTermOrPhraseNumber();
}
{code:java}
This call to {{nextTermOrPhraseNumber()}} increments the term number I guess
because we have already seen the term {{BBB}} previously.
I'm going to join a test case patch.
was:
I'm indexing a document with a field which is {{aaa bbb ccc ddd bbb eee fff}}.
I'm running a Bool Query which contains 2 should Phrase queries: {{aaa bbb}}
and {{eee fff}}.
I'm using an FVH with two tags {{<1>}} and {{<2>}}.
It gives the correct result: {{<1>aaa bbb ccc ddd bbb <2>eee fff}}
With same settings, I'm now running with 2 should Phrase queries: {{aaa bbb}}
and {{bbb eee}}.
I'm getting back a wrong result: {{<1>aaa bbb ccc ddd <1>bbb eee fff}}
where I'm expecting {{<1>aaa bbb ccc ddd <2>bbb eee fff}}.
Why this?
Apparently the FVH is getting back as sequence numbers in the first case {{0}}
and {{1}} but in the second case {{0}} and {{2}}.
The problem is when we call then {{getPreTag}}, we are getting the first tag
instead of the second one:
{{code:java}}
protected String getPreTag( String[] preTags, int num ){
int n = num % preTags.length;
return preTags[n];
}
protected String getPostTag( String[] postTags, int num ){
int n = num % postTags.length;
return postTags[n];
}
{{code:java}}
I did not find yet how to fix that. But I believe it is somewhere in
{{org.apache.lucene.search.vectorhighlight.FieldQuery}} class
{{code:java}}
private void markTerminal( int slop, float boost ){
this.terminal = true;
this.slop = slop;
this.boost = boost;
this.termOrPhraseNumber = fieldQuery.nextTermOrPhraseNumber();
}
{{code:java}}
This call to {{nextTermOrPhraseNumber()}} increments the term number I guess
because we have already seen the term {{BBB}} previously.
I'm going to join a test case patch.
> FVH does not work well with phrases and multiple tags
> -
>
> Key: LUCENE-7541
> URL: https://issues.apache.org/jira/browse/LUCENE-7541
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/highlighter
>Affects Versions: trunk, 6.x
>Reporter: David Pilato
> Attachments: Add_test_for_FVH_with_phrase_and_multiple_tags_.patch
>
>
> I'm indexing a document with a field which is {{aaa bbb ccc ddd bbb eee fff}}.
> I'm running a Bool Query which contains 2 should Phrase queries: {{aaa bbb}}
> and {{eee fff}}.
> I'm using an FVH with two tags {{<1>}} and {{<2>}}.
> It gives the correct result: {{<1>aaa bbb ccc ddd bbb <2>eee fff}}
> With same settings, I'm now running with 2 should Phrase queries: {{aaa bbb}}
> and {{bbb eee}}.
> I'm getting back a wrong result: {{<1>aaa bbb ccc ddd <1>bbb eee
> fff}} where I'm expecting {{<1>aaa bbb ccc ddd <2>bbb eee fff}}.
> Why this?
> Apparently the FVH is getting back as sequence numbers in the first case
> {{0}} and {{1}} but in the second case {{0}} and {{2}}.
> The problem is when we call then {{getPreTag}}, we are getting the first tag
> instead of the second one:
> {code:java}
> protected String getPreTag( String[] preTags, int num ){
> int n = num % preTags.length;
> return preTags[n];
> }
>
> protected String getPostTag( String[] postTags, int num ){
> int n = num % postTags.length;
> return postTags[n];
> }
> {code:java}
> I did not find yet how
[jira] [Commented] (LUCENE-6824) TermAutomatonQuery should rewrite to a simpler query when possible
[
https://issues.apache.org/jira/browse/LUCENE-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643847#comment-15643847
]
ASF subversion and git services commented on LUCENE-6824:
-
Commit c294d3f08317eb9139f32bfbde1b27e7eb134653 in lucene-solr's branch
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c294d3f ]
LUCENE-6824: TermAutomatonQuery now rewrites to TermQuery, PhraseQuery or
MultiPhraseQuery when the word automaton is simple
> TermAutomatonQuery should rewrite to a simpler query when possible
> --
>
> Key: LUCENE-6824
> URL: https://issues.apache.org/jira/browse/LUCENE-6824
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.4
>
> Attachments: LUCENE-6824.patch, LUCENE-6824.patch
>
>
> Spinoff from LUCENE-6664.
> I think {{TermAutomatonQuery}} would be easier to integrate into query
> parsers if you could simply use it always and it would rewrite to simpler /
> faster queries when possible.
> This way, when a query parser is confronted with a phrase query requested by
> the user, it can just make a {{TermAutomatonQuery}} and run that.
> But the non-explicit phrase query case is still tricky...
--
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] (LUCENE-7541) FVH does not work well with phrases and multiple tags
David Pilato created LUCENE-7541:
Summary: FVH does not work well with phrases and multiple tags
Key: LUCENE-7541
URL: https://issues.apache.org/jira/browse/LUCENE-7541
Project: Lucene - Core
Issue Type: Bug
Components: modules/highlighter
Affects Versions: trunk, 6.x
Reporter: David Pilato
Attachments: Add_test_for_FVH_with_phrase_and_multiple_tags_.patch
I'm indexing a document with a field which is {{aaa bbb ccc ddd bbb eee fff}}.
I'm running a Bool Query which contains 2 should Phrase queries: {{aaa bbb}}
and {{eee fff}}.
I'm using an FVH with two tags {{<1>}} and {{<2>}}.
It gives the correct result: {{<1>aaa bbb ccc ddd bbb <2>eee fff}}
With same settings, I'm now running with 2 should Phrase queries: {{aaa bbb}}
and {{bbb eee}}.
I'm getting back a wrong result: {{<1>aaa bbb ccc ddd <1>bbb eee fff}}
where I'm expecting {{<1>aaa bbb ccc ddd <2>bbb eee fff}}.
Why this?
Apparently the FVH is getting back as sequence numbers in the first case {{0}}
and {{1}} but in the second case {{0}} and {{2}}.
The problem is when we call then {{getPreTag}}, we are getting the first tag
instead of the second one:
{{code:java}}
protected String getPreTag( String[] preTags, int num ){
int n = num % preTags.length;
return preTags[n];
}
protected String getPostTag( String[] postTags, int num ){
int n = num % postTags.length;
return postTags[n];
}
{{code:java}}
I did not find yet how to fix that. But I believe it is somewhere in
{{org.apache.lucene.search.vectorhighlight.FieldQuery}} class
{{code:java}}
private void markTerminal( int slop, float boost ){
this.terminal = true;
this.slop = slop;
this.boost = boost;
this.termOrPhraseNumber = fieldQuery.nextTermOrPhraseNumber();
}
{{code:java}}
This call to {{nextTermOrPhraseNumber()}} increments the term number I guess
because we have already seen the term {{BBB}} previously.
I'm going to join a test case patch.
--
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] (LUCENE-6824) TermAutomatonQuery should rewrite to a simpler query when possible
[
https://issues.apache.org/jira/browse/LUCENE-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-6824.
Resolution: Fixed
Fix Version/s: (was: 6.3)
6.4
> TermAutomatonQuery should rewrite to a simpler query when possible
> --
>
> Key: LUCENE-6824
> URL: https://issues.apache.org/jira/browse/LUCENE-6824
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.4
>
> Attachments: LUCENE-6824.patch, LUCENE-6824.patch
>
>
> Spinoff from LUCENE-6664.
> I think {{TermAutomatonQuery}} would be easier to integrate into query
> parsers if you could simply use it always and it would rewrite to simpler /
> faster queries when possible.
> This way, when a query parser is confronted with a phrase query requested by
> the user, it can just make a {{TermAutomatonQuery}} and run that.
> But the non-explicit phrase query case is still tricky...
--
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-7541) FVH does not work well with phrases and multiple tags
[
https://issues.apache.org/jira/browse/LUCENE-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Pilato updated LUCENE-7541:
-
Attachment: Add_test_for_FVH_with_phrase_and_multiple_tags_.patch
Test case
> FVH does not work well with phrases and multiple tags
> -
>
> Key: LUCENE-7541
> URL: https://issues.apache.org/jira/browse/LUCENE-7541
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/highlighter
>Affects Versions: trunk, 6.x
>Reporter: David Pilato
> Attachments: Add_test_for_FVH_with_phrase_and_multiple_tags_.patch
>
>
> I'm indexing a document with a field which is {{aaa bbb ccc ddd bbb eee fff}}.
> I'm running a Bool Query which contains 2 should Phrase queries: {{aaa bbb}}
> and {{eee fff}}.
> I'm using an FVH with two tags {{<1>}} and {{<2>}}.
> It gives the correct result: {{<1>aaa bbb ccc ddd bbb <2>eee fff}}
> With same settings, I'm now running with 2 should Phrase queries: {{aaa bbb}}
> and {{bbb eee}}.
> I'm getting back a wrong result: {{<1>aaa bbb ccc ddd <1>bbb eee
> fff}} where I'm expecting {{<1>aaa bbb ccc ddd <2>bbb eee fff}}.
> Why this?
> Apparently the FVH is getting back as sequence numbers in the first case
> {{0}} and {{1}} but in the second case {{0}} and {{2}}.
> The problem is when we call then {{getPreTag}}, we are getting the first tag
> instead of the second one:
> {{code:java}}
> protected String getPreTag( String[] preTags, int num ){
> int n = num % preTags.length;
> return preTags[n];
> }
>
> protected String getPostTag( String[] postTags, int num ){
> int n = num % postTags.length;
> return postTags[n];
> }
> {{code:java}}
> I did not find yet how to fix that. But I believe it is somewhere in
> {{org.apache.lucene.search.vectorhighlight.FieldQuery}} class
> {{code:java}}
> private void markTerminal( int slop, float boost ){
> this.terminal = true;
> this.slop = slop;
> this.boost = boost;
> this.termOrPhraseNumber = fieldQuery.nextTermOrPhraseNumber();
> }
> {{code:java}}
> This call to {{nextTermOrPhraseNumber()}} increments the term number I guess
> because we have already seen the term {{BBB}} previously.
> I'm going to join a test case patch.
--
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-6824) TermAutomatonQuery should rewrite to a simpler query when possible
[
https://issues.apache.org/jira/browse/LUCENE-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15643844#comment-15643844
]
ASF subversion and git services commented on LUCENE-6824:
-
Commit cc99815dcbaa796d717601d600645e658eb9f882 in lucene-solr's branch
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cc99815 ]
LUCENE-6824: TermAutomatonQuery now rewrites to TermQuery, PhraseQuery or
MultiPhraseQuery when the word automaton is simple
> TermAutomatonQuery should rewrite to a simpler query when possible
> --
>
> Key: LUCENE-6824
> URL: https://issues.apache.org/jira/browse/LUCENE-6824
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.3
>
> Attachments: LUCENE-6824.patch, LUCENE-6824.patch
>
>
> Spinoff from LUCENE-6664.
> I think {{TermAutomatonQuery}} would be easier to integrate into query
> parsers if you could simply use it always and it would rewrite to simpler /
> faster queries when possible.
> This way, when a query parser is confronted with a phrase query requested by
> the user, it can just make a {{TermAutomatonQuery}} and run that.
> But the non-explicit phrase query case is still tricky...
--
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-9736) HttpSolrCall always prefer leader
[ https://issues.apache.org/jira/browse/SOLR-9736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-9736: --- Attachment: SOLR-9736.patch The first attempt for this issue. > HttpSolrCall always prefer leader > - > > Key: SOLR-9736 > URL: https://issues.apache.org/jira/browse/SOLR-9736 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat > Attachments: SOLR-9736.patch > > > Currently, `HttpSolrCall.getCoreByCollection` always picks the first > available leader ( or first replica ) of the first slice. It puts undue > pressure on leaders and quite possibly on the wrong ones -- 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-9736) HttpSolrCall always prefer leader
Cao Manh Dat created SOLR-9736: -- Summary: HttpSolrCall always prefer leader Key: SOLR-9736 URL: https://issues.apache.org/jira/browse/SOLR-9736 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Cao Manh Dat Currently, `HttpSolrCall.getCoreByCollection` always picks the first available leader ( or first replica ) of the first slice. It puts undue pressure on leaders and quite possibly on the wrong ones -- 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: [VOTE] - Release Lucene/Solr 6.3.0 RC3
+1 SUCCESS! [0:29:01.118046] Mike McCandless http://blog.mikemccandless.com On Fri, Nov 4, 2016 at 10:41 PM, Tomás Fernández Löbbe wrote: > +1 > > SUCCESS! [1:03:34.743909] > > On Thu, Nov 3, 2016 at 8:09 AM, Adrien Grand wrote: >> >> +1 SUCCESS! [1:02:33.485442] >> >> Le jeu. 3 nov. 2016 à 00:19, Steve Rowe a écrit : >>> >>> +1 >>> >>> Smoke tester passed (lost the timing in a closed terminal window, it was >>> 34 minutes or so IIRC). >>> >>> Changes, docs and javadocs look good. >>> >>> -- >>> Steve >>> www.lucidworks.com >>> >>> > On Nov 2, 2016, at 3:35 PM, Tommaso Teofili >>> > wrote: >>> > >>> > SUCCESS! [1:54:38.816517] >>> > >>> > +1 >>> > >>> > Tommaso >>> > >>> > >>> > Il giorno mer 2 nov 2016 alle ore 19:56 Jan Høydahl >>> > ha scritto: >>> > SUCCESS! [1:05:53.149540] (macOS) >>> > +1 >>> > >>> > -- >>> > Jan Høydahl, search solution architect >>> > Cominvent AS - www.cominvent.com >>> > >>> >> 2. nov. 2016 kl. 17.34 skrev Shalin Shekhar Mangar >>> >> : >>> >> >>> >> Please vote for the third release candidate for Lucene/Solr 6.3.0 >>> >> >>> >> The artifacts can be downloaded from: >>> >> >>> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316 >>> >> >>> >> You can run the smoke tester directly with this command: >>> >> python3 -u dev-tools/scripts/smokeTestRelease.py >>> >> >>> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316 >>> >> >>> >> Smoke tester passed for me: >>> >> SUCCESS! [0:36:45.760510] >>> >> >>> >> Here's my +1 to release. >>> >> >>> >> -- >>> >> Regards, >>> >> Shalin Shekhar Mangar. >>> >> >>> >> - >>> >> 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: [JENKINS] Lucene-Solr-SmokeRelease-master - Build # 611 - Still Failing
I removed the tabs from solr/example/files/conf/update-script.js. Le lun. 7 nov. 2016 à 10:08, Apache Jenkins Server < jenk...@builds.apache.org> a écrit : > Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/611/ > > No tests ran. > > Build Log: > [...truncated 41957 lines...] > prepare-release-no-sign: > [mkdir] Created dir: > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist > [copy] Copying 476 files to > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene > [copy] Copying 260 files to > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr >[smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 >[smoker] NOTE: output encoding is UTF-8 >[smoker] >[smoker] Load release URL > "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"... >[smoker] >[smoker] Test Lucene... >[smoker] test basics... >[smoker] get KEYS >[smoker] 0.2 MB in 0.01 sec (16.0 MB/sec) >[smoker] check changes HTML... >[smoker] download lucene-7.0.0-src.tgz... >[smoker] 30.0 MB in 0.04 sec (819.5 MB/sec) >[smoker] verify md5/sha1 digests >[smoker] download lucene-7.0.0.tgz... >[smoker] 64.6 MB in 0.08 sec (849.0 MB/sec) >[smoker] verify md5/sha1 digests >[smoker] download lucene-7.0.0.zip... >[smoker] 75.3 MB in 0.09 sec (851.5 MB/sec) >[smoker] verify md5/sha1 digests >[smoker] unpack lucene-7.0.0.tgz... >[smoker] verify JAR metadata/identity/no javax.* or java.* > classes... >[smoker] test demo with 1.8... >[smoker] got 6088 hits for query "lucene" >[smoker] checkindex with 1.8... >[smoker] check Lucene's javadoc JAR >[smoker] unpack lucene-7.0.0.zip... >[smoker] verify JAR metadata/identity/no javax.* or java.* > classes... >[smoker] test demo with 1.8... >[smoker] got 6088 hits for query "lucene" >[smoker] checkindex with 1.8... >[smoker] check Lucene's javadoc JAR >[smoker] unpack lucene-7.0.0-src.tgz... >[smoker] make sure no JARs/WARs in src dist... >[smoker] run "ant validate" >[smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... >[smoker] test demo with 1.8... >[smoker] got 213 hits for query "lucene" >[smoker] checkindex with 1.8... >[smoker] generate javadocs w/ Java 8... >[smoker] >[smoker] Crawl/parse... >[smoker] >[smoker] Verify... >[smoker] confirm all releases have coverage in > TestBackwardsCompatibility >[smoker] find all past Lucene releases... >[smoker] run TestBackwardsCompatibility.. >[smoker] success! >[smoker] >[smoker] Test Solr... >[smoker] test basics... >[smoker] get KEYS >[smoker] 0.2 MB in 0.00 sec (191.6 MB/sec) >[smoker] check changes HTML... >[smoker] download solr-7.0.0-src.tgz... >[smoker] 39.5 MB in 0.05 sec (794.4 MB/sec) >[smoker] verify md5/sha1 digests >[smoker] download solr-7.0.0.tgz... >[smoker] 139.6 MB in 0.18 sec (795.2 MB/sec) >[smoker] verify md5/sha1 digests >[smoker] download solr-7.0.0.zip... >[smoker] 148.9 MB in 0.19 sec (786.7 MB/sec) >[smoker] verify md5/sha1 digests >[smoker] unpack solr-7.0.0.tgz... >[smoker] verify JAR metadata/identity/no javax.* or java.* > classes... >[smoker] unpack lucene-7.0.0.tgz... >[smoker] **WARNING**: skipping check of > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: > it has javax.* classes >[smoker] **WARNING**: skipping check of > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: > it has javax.* classes >[smoker] copying unpacked distribution for Java 8 ... >[smoker] test solr example w/ Java 8... >[smoker] start Solr instance > (log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)... >[smoker] No process found for Solr node running on port 8983 >[smoker] Running techproducts example on port 8983 from > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8 >[smoker] Creating Solr home directory > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr >[smoker] >
[jira] [Updated] (SOLR-9727) solr.in.sh properties does not set the correct values.
[
https://issues.apache.org/jira/browse/SOLR-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Suzuki updated SOLR-9727:
-
Description:
When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or
SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false.
{code}
SOLR_SSL_NEED_CLIENT_AUTH=true
SOLR_SSL_WANT_CLIENT_AUTH=false
{code}
To recreate the issue:
1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
2) Start solr with remote debugging.
3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
Expected value for needClientAuth should be true instead its false.
was:
When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or
SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false.
To recreate the issue:
1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
2) Start solr with remote debugging.
3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
Expected value for needClientAuth should be true instead its false.
> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 6.3
>Reporter: Michael Suzuki
>Assignee: Michael Suzuki
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false.
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.
--
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
