[jira] [Commented] (LUCENE-7788) fail precommit on unparameterised log.trace messages

[Michael Braun (JIRA)]

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

Michael Braun commented on LUCENE-7788:
---

Another thing I've noticed is sometimes there are log statements with explicit 
.toString()s on the parameters, which defeats the point of using the 
parameterized logging. Something to think about / include potentially? 

> fail precommit on unparameterised log.trace messages
> 
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7788.patch
>
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-6630:
--

bq. I'd suggest to rename the implicit router to "userDefined".

So this belongs to a third emphasis category:

* Emphasizing that routing is the client's responsibility, not the server's: 
"manual", "custom", "userDefined"



> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-1485) Payload scoring support

[Erik Hatcher (JIRA)]

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

Erik Hatcher edited comment on SOLR-1485 at 4/19/17 3:29 PM:
-

While I'm at it, I found that Lucene's {{PayloadScoreQuery}} had a 
.equals/hashCode/cache bug in that it didn't take into account the 
{{includeSpanScore}} flag - fixed here.


was (Author: ehatcher):
While I'm at it, I found that Lucene's {{PayloadScoreQuery}} had a 
.equals/hashCode/cache bug in that it didn't into account the includeSpanScore 
flag - fixed here.

> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, 
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch
>
>
> Solr has no support for Lucene's PayloadScoreQuery, yet it has support for 
> indexing payloads (via DelimitedPayloadTokenFilter or 
> NumericPayloadTokenFilter). 
> This issue adds value source and query parser support for leveraging payloads 
> created by those token filters.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (LUCENE-7788) fail precommit on unparameterised log.trace messages

[Christine Poerschke (JIRA)]

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

Christine Poerschke edited comment on LUCENE-7788 at 4/19/17 3:20 PM:
--

bq. ... Also, should we remove the {{if (trace)}} from {{TransactionLog}} if we 
do that? ...

Yes, attaching revised patch.


was (Author: cpoerschke):
bq. ... Also, should we remove the if (trace) from TransactionLog if we do 
that? ...

Yes, attaching revised patch.

> fail precommit on unparameterised log.trace messages
> 
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7788.patch, LUCENE-7788.patch
>
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7788) fail precommit on unparameterised log.trace messages

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated LUCENE-7788:

Attachment: LUCENE-7788.patch

bq. ... Also, should we remove the if (trace) from TransactionLog if we do 
that? ...

Yes, attaching revised patch.

> fail precommit on unparameterised log.trace messages
> 
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7788.patch, LUCENE-7788.patch
>
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9824) Documents indexed in bulk are replicated using too many HTTP requests

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9824:
---

Once I get back to some beasting test runs on master. There were still a test 
or two hanging last time I tried to do a report and I want to rule this out 
first.

> Documents indexed in bulk are replicated using too many HTTP requests
> -
>
> Key: SOLR-9824
> URL: https://issues.apache.org/jira/browse/SOLR-9824
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.3
>Reporter: David Smiley
>Assignee: Mark Miller
> Attachments: SOLR-9824.patch, SOLR-9824.patch, SOLR-9824.patch, 
> SOLR-9824.patch, SOLR-9824.patch, SOLR-9824.patch, SOLR-9824.patch
>
>
> This takes awhile to explain; bear with me. While working on bulk indexing 
> small documents, I looked at the logs of my SolrCloud nodes.  I noticed that 
> shards would see an /update log message every ~6ms which is *way* too much.  
> These are requests from one shard (that isn't a leader/replica for these docs 
> but the recipient from my client) to the target shard leader (no additional 
> replicas).  One might ask why I'm not sending docs to the right shard in the 
> first place; I have a reason but it's besides the point -- there's a real 
> Solr perf problem here and this probably applies equally to 
> replicationFactor>1 situations too.  I could turn off the logs but that would 
> hide useful stuff, and it's disconcerting to me that so many short-lived HTTP 
> requests are happening, somehow at the bequest of DistributedUpdateProcessor. 
>  After lots of analysis and debugging and hair pulling, I finally figured it 
> out.  
> In SOLR-7333 ([~tpot]) introduced an optimization called 
> {{UpdateRequest.isLastDocInBatch()}} in which ConcurrentUpdateSolrClient will 
> poll with a '0' timeout to the internal queue, so that it can close the 
> connection without it hanging around any longer than needed.  This part makes 
> sense to me.  Currently the only spot that has the smarts to set this flag is 
> {{JavaBinUpdateRequestCodec.unmarshal.readOuterMostDocIterator()}} at the 
> last document.  So if a shard received docs in a javabin stream (but not 
> other formats) one would expect the _last_ document to have this flag.  
> There's even a test.  Docs without this flag get the default poll time; for 
> javabin it's 25ms.  Okay.
> I _suspect_ that if someone used CloudSolrClient or HttpSolrClient to send 
> javabin data in a batch, the intended efficiencies of SOLR-7333 would apply.  
> I didn't try. In my case, I'm using ConcurrentUpdateSolrClient (and BTW 
> DistributedUpdateProcessor uses CUSC too).  CUSC uses the RequestWriter 
> (defaulting to javabin) to send each document separately without any leading 
> marker or trailing marker.  For the XML format by comparison, there is a 
> leading and trailing marker ( ... ).  Since there's no outer 
> container for the javabin unmarshalling to detect the last document, it marks 
> _every_ document as {{req.lastDocInBatch()}}!  Ouch!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7788) fail precommit on unparameterised log.trace messages

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on LUCENE-7788:
-

bq. ... it only catches cases when the logger is called {{log}} ...

Looks like the {{validLoggerPattern}} at 
https://github.com/apache/lucene-solr/blob/master/build.xml#L174 is flexible on 
names but in practice {{log}} is the most popular choice:
{code}
git grep " = LoggerFactory.getLogger" | sed 's/.* \(.* = 
\)LoggerFactory.*/\1/g' | sort | uniq -c | sort -nr
 482 log = 
  57 LOG = 
  23 logger = 
   1 requestLog = 
{code}

So one option might be to change the 57+23+1 loggers that are not called 
{{log}} and to then standardise on {{log}} via the validLoggerPattern and to 
then proceed with some sort of check for {{log.trace}} and in due course 
perhaps also {{log.debug}}?


> fail precommit on unparameterised log.trace messages
> 
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7788.patch
>
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10047) Mismatched Docvalue segments cause exception in Sorting/Facting; Uninvert per segment

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10047:
---

Policeman Jenkins failure reproduces for me 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19429/]:

{noformat}
Checking out Revision 48d54ac45860a1b75bfd79aaffe9d4d24c2ad5a8 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=DocValuesTest 
-Dtests.method=testHalfAndHalfDocValues -Dtests.seed=D4C321F7B9F8C0F3 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=hu-HU 
-Dtests.timezone=WET -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.04s J1 | DocValuesTest.testHalfAndHalfDocValues <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<3> but 
was:<2>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([D4C321F7B9F8C0F3:1B0859436D75536E]:0)
   [junit4]>at 
org.apache.solr.schema.DocValuesTest.testHalfAndHalfDocValues(DocValuesTest.java:192)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
sim=RandomSimilarity(queryNorm=false): {}, locale=hu-HU, timezone=WET
   [junit4]   2> NOTE: Linux 4.4.0-72-generic i386/Oracle Corporation 1.8.0_121 
(32-bit)/cpus=12,threads=1,free=146280496,total=518979584
{noformat}

When I run the repro line on my Linux box, the actual value was {{1}} instead 
of the {{2}} though, so at a minimum there's some flakiness here:

{{[junit4]> Throwable #1: java.lang.AssertionError: expected:<3> but 
was:<1>}}

> Mismatched Docvalue segments cause exception in Sorting/Facting; Uninvert per 
> segment
> -
>
> Key: SOLR-10047
> URL: https://issues.apache.org/jira/browse/SOLR-10047
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Keith Laban
>Assignee: Shalin Shekhar Mangar
> Fix For: 6.6, master (7.0)
>
>
> The configuration of UninvertingReader in SolrIndexSearch creates a global 
> mapping for the directory for fields to uninvert. If docvalues are enabled on 
> a field the creation of a new segment will cause the query to fail when 
> faceting/sorting on the recently docvalue enabled field. This happens because 
> the UninvertingReader is configured globally across the entire directory, and 
> a single segment containing DVs for a field will incorrectly indicate that 
> all segments contain DVs.
> This patch addresses the incorrect behavior by determining the fields to be 
> uninverted on a per-segment basis.
> With the fix, it is still recommended that a reindexing occur as data loss 
> will when a DV and non-DV segment are merged, SOLR-10046 addresses this 
> behavior. This fix is to be a stop gap for the time between enabling 
> docvalues and the duration of a reindex. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7788) fail precommit on unparameterised log.trace messages

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7788:


bq. It looks a bit fragile to me as it only catches cases when the logger is 
called log while Solr seems to have some loggers called LOG, logger or even 
requestLog? Also, should we remove the if (trace) from TransactionLog if we do 
that?

Could forbidden-apis be used here instead?

> fail precommit on unparameterised log.trace messages
> 
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7788.patch
>
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-9555 at 4/19/17 2:45 PM:


bq. We close the followers' connections, and then need to send a doc so that it 
can fail to distribute and that is what triggers the LIR.

This comment applies to that: And I suppose to hit the leader we would have to 
hit the actual leader jetty port (there should be the proxy port, and the legit 
jetty port). I assume that is still possible? Have not looked into it.


was (Author: markrmil...@gmail.com):
bq. We close the followers' connections, and then need to send a doc so that it 
can fail to distribute and that is what triggers the LIR.

This comment applies to that: And I suppose to hit the leader we would have to 
hit the actual leader jetty port. I assume that is still possible? Have not 
looked into it.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP-2.patch, SOLR-9555-WIP-3.patch, 
> SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10415) Within solr-core, debug/trace level logging should use parameterized log messages

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10415:


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

(part 1 of several) SOLR-10415: use parameterized debug logging in 
SearchHandler and RealTimeGetComponent (Michael Braun via Christine Poerschke)


> Within solr-core, debug/trace level logging should use parameterized log 
> messages
> -
>
> Key: SOLR-10415
> URL: https://issues.apache.org/jira/browse/SOLR-10415
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Michael Braun
>Priority: Trivial
>
> Noticed in several samplings of an active Solr that several debug statements 
> were taking decently measurable time because of the time of the .toString 
> even when the log.debug() statement would not output because it was 
> effectively INFO or higher. Using parameterized logging statements, ie 
> 'log.debug("Blah {}", o)' will avoid incurring that cost.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-5127) Allow multiple wildcards in hl.fl

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5127: Multiple highlight fields and wildcards are now supported e.g. 
hl.fl=title,text_*
(Sven-S. Porst, Daniel Debray, Simon Endele, Christine Poerschke)


> Allow multiple wildcards in hl.fl
> -
>
> Key: SOLR-5127
> URL: https://issues.apache.org/jira/browse/SOLR-5127
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 3.6.1, 4.4
>Reporter: Sven-S. Porst
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: highlight-wildcards.patch, SOLR-5127.patch, 
> SOLR-5127.patch, SOLR-5127.patch
>
>
> When a wildcard is present in the hl.fl field, the field is not split up at 
> commas/spaces into components. As a consequence settings like 
> hl.fl=*_highlight,*_data do not work.
> Splitting the string first and evaluating wildcards on each component 
> afterwards would be more powerful and consistent with the documentation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10394) search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10394:


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

SOLR-10394: a few more essentially non-public sortWithinGroup to 
withinGroupSort renames

Resolved Conflict:

solr/core/src/java/org/apache/solr/search/grouping/distributed/command/TopGroupsFieldCommand.java


> search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort
> -
>
> Key: SOLR-10394
> URL: https://issues.apache.org/jira/browse/SOLR-10394
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10394-part2.patch, SOLR-10394.patch
>
>
> The class is marked _@lucene.experimental_ and SOLR-9660 previously included 
> sortSpecWithinGroup to withinGroupSortSpec renaming for GroupSpecification; 
> the rename proposed here is in line with that.
> Motivation for the change is to reduce group-sort vs. within-group-sort 
> confusion, generally and specifically in SOLR-6203.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7788) fail precommit on unparameterised log.trace messages

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7788:
--

It looks a bit fragile to me as it only catches cases when the logger is called 
{{log}} while Solr seems to have some loggers called {{LOG}}, {{logger}} or 
even {{requestLog}}? Also, should we remove the {{if (trace)}} from 
{{TransactionLog}} if we do that?

> fail precommit on unparameterised log.trace messages
> 
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7788.patch
>
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9104) NPE in CollapsingQParser when two fq={!collapse} and zero results

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-9104:
-

NPE is still present, stack trace is slightly different today:

{code}
2017-04-19 14:41:18.657 ERROR (qtp331844619-249) [c:logs s:shard2 r:core_node4 
x:logs_shard2_replica2] o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
at 
org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:617)
at 
org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:667)
at 
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:240)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:2027)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1844)
at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:609)
at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:547)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295
{code}

> NPE in CollapsingQParser when two fq={!collapse} and zero results
> -
>
> Key: SOLR-9104
> URL: https://issues.apache.org/jira/browse/SOLR-9104
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
> Fix For: 6.2, master (7.0)
>
>
> This is a very weird problem that is reproducible on a small production 
> server, but not on the local machine although they run the same 6.0 version., 
> and have an almost identical index. The only minor difference is that 
> production is a SolrCloud with 1 shard and two replica's, just for a bit of 
> redundancy.
> The following query yields zero results and throws the NPE:
> {code}
> select?q=query:seis={!collapse field=query_digest}={!collapse 
> field=result_digest}
> {code}
> The next query does yield results and does not throw anything, it just works 
> as it should work:
> {code}
> select?q=query:seiz={!collapse field=query_digest}={!collapse 
> field=result_digest}
> {code}
> The /select handler used does not add any fancy param other than rows.
> Here's the NPE:
> {code}
> 2016-05-11 14:10:27.666 ERROR (qtp1209271652-3338) [c:suggestions s:shard1 
> r:core_node1 x:suggestions_shard1_replica1] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:814)
> at 
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:851)
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:272)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1794)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1611)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:634)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:529)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:287)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> {code}
> Edit: for the sake of clarity. It really needs double fq={!collapse bla bla 
> for the NPE to appear. If i remove either of the filters from the query, i 
> get a nice zero resultset back. Both fields are defined as int.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Andriy Rysin (JIRA)]

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

Andriy Rysin commented on LUCENE-7785:
--

Thanks Dawid! Thanks everybody for your help and feedback!

> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 6.x, master (7.0), 6.6
>
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Trey Cahill (JIRA)]

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

Trey Cahill commented on SOLR-6630:
---

I'd suggest to rename the implicit router to "userDefined".  

I think it would provide the least amount of ambiguity to a new user, as when 
using it, the user defines what shard documents are sent too.

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Solr JMX changes and backwards (in)compatibility

[Walter Underwood]

I did report it a week ago. This is a reply to that email.

New Relic displays the cache hit rate for each collection, showing the query 
result cache, filter cache, and document cache.

With 6.5.0, that page shows this message:

New Relic recorded no Solr caches data for this application in the last 24 
hours
If you think there should be Solr data here, first check to see that JMX is 
enabled for your application server. If enabled, then please contact support.

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


> On Apr 19, 2017, at 2:28 AM, Andrzej Białecki 
>  wrote:
> 
> 
>> On 18 Apr 2017, at 19:15, Walter Underwood > > wrote:
>> 
>> Pretty sure the back-compat did not work, because New Relic cannot find the 
>> MBeans in our 6.5.0 cluster.
>> 
> 
> I don’t use New Relic and nobody reported this until now, which is a pity… 
> Could you please be more specific about what MBeans can’t be found? Does this 
> affect all caches or just some of them? 
> 
>> 
>>> On Apr 11, 2017, at 2:28 PM, Walter Underwood >> > wrote:
>>> 
>>> We are running 6.5.0 in prod and New Relic is not showing cache stats. I 
>>> think this means it cannot find the MBeans.
>>> 
>>> I gleaned that from the discussion here:
>>> 
>>> https://discuss.newrelic.com/t/solr-data-not-appearing-in-apm-solr-tabs-caches-updates/37507/4
>>>  
>>> 
>>> https://docs.newrelic.com/docs/agents/java-agent/troubleshooting/solr-data-not-appearing-apm-solr-tab-java
>>>  
>>> 
>>> 
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org 
>>> http://observer.wunderwood.org/   (my blog)
>>> 
 On Mar 3, 2017, at 7:26 AM, Andrzej Białecki 
 > 
 wrote:
 
 
> On 2 Mar 2017, at 16:45, Otis Gospodnetić  > wrote:
> 
> Hi,
> 
> While I love all the new metrics in Solr, I think metrics should be 
> treated like code/features in terms of how backwards 
> compatibility/deprecation is handled. Otherwise, on upgrade, people's 
> monitoring breaks and monitoring is kind of important... 
> Note: Looks like recent Solr metrics changes broke/changed 
> previously-existing MBeans... 
> Don't have the details about what was changed and how exactly, but I see 
> people using Sematext SPM for monitoring Solr are reporting this with 
> Solr 6.4.1.
> 
 
 Otis,
 
 Yes, we’ll be more careful, but we need proper feedback too. My 
 understanding was that SOLR-10035 addressed this by adding back-combat 
 registration under old names. Are you saying there are still some issues 
 in 6.4.1? Can you please be more specific? 6.4.2 is almost out, but if 
 it’s something serious then we should fix it.
 
> 
> Otis
> --
> Monitoring - Log Management - Alerting - Anomaly Detection
> Solr & Elasticsearch Consulting Support Training - http://sematext.com/ 
> 
> 
 
>>> 
>> 
> 

[jira] [Comment Edited] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-9555 at 4/19/17 2:44 PM:


bq. So I get the impression that closing a proxy only prevents inbound 
connections, not outbound connections, which is why the followers are able to 
recover gracefully. 

Yes, the idea of the proxy is simple afaik. It pipes from one port to another, 
and so lets you cut off the connection or play other weird games if you want. 
The is the port jetty listens out, there is no interaction with outbound 
connections. That is why the ForceLeaderTest is not written correctly. I think 
you can write it correctly as I describe above though with a few simple changes.

bq. Interestingly, removing the 2 second sleep allows the test to pass for me, 
and I can't see how it invalidates the premises under test here.

I don't know that it invalidates anything, it just is a little flakey and 
failure prone to count on something like this, especially with all the env and 
gc events and parallel tests we run. We want rock solid.


was (Author: markrmil...@gmail.com):
bq. So I get the impression that closing a proxy only prevents inbound 
connections, not outbound connections, which is why the followers are able to 
recover gracefully. 

Yes, the idea of the proxy is simple afaik. It pipes from one port to another, 
and so lets you cut off the connection or play other weird games if you want. 
The is the port jetty listens out, there is no interaction without outbound 
connections. That is why the ForceLeaderTest is not written correctly. I think 
you can write it correctly as I describe above though with a few simple changes.

bq. Interestingly, removing the 2 second sleep allows the test to pass for me, 
and I can't see how it invalidates the premises under test here.

I don't know that it invalidates anything, it just is a little flakey and 
failure prone to count on something like this, especially with all the env and 
gc events and parallel tests we run. We want rock solid.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP-2.patch, SOLR-9555-WIP-3.patch, 
> SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

bq. So I get the impression that closing a proxy only prevents inbound 
connections, not outbound connections, which is why the followers are able to 
recover gracefully. 

Yes, the idea of the proxy is simple afaik. It pipes from one port to another, 
and so lets you cut off the connection or play other weird games if you want. 
The is the port jetty listens out, there is no interaction without outbound 
connections. That is why the ForceLeaderTest is not written correctly. I think 
you can write it correctly as I describe above though with a few simple changes.

bq. Interestingly, removing the 2 second sleep allows the test to pass for me, 
and I can't see how it invalidates the premises under test here.

I don't know that it invalidates anything, it just is a little flakey and 
failure prone to count on something like this, especially with all the env and 
gc events and parallel tests we run. We want rock solid.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP-2.patch, SOLR-9555-WIP-3.patch, 
> SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

bq. We close the followers' connections, and then need to send a doc so that it 
can fail to distribute and that is what triggers the LIR.

This comment applies to that: And I suppose to hit the leader we would have to 
hit the actual leader jetty port. I assume that is still possible? Have not 
looked into it.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP-2.patch, SOLR-9555-WIP-3.patch, 
> SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

If everything else is in order though, I can try and tackle that test before 
commit. I'm pretty sure we can bypass the proxy to send updates to the leader. 
There are a lot of things we might want to test like this.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP-2.patch, SOLR-9555-WIP-3.patch, 
> SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-6630:
--

bq. Another alternative to "manual" that came to mind was "custom".

To me "custom" implies configurable variability, which is not what's going on.

Some more alternatives: 

* Emphasizing the fact the implicit router does nothing: "null", "void", "no-op"
* Emphasizing the non-displacing aspect of the implicit router's function: 
"in-place", "in-situ", "static"

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-6630 at 4/19/17 1:42 PM:
---

bq. Another alternative to "manual" that came to mind was "custom".

To me "custom" implies configurable variability, which is not what's going on.

Some more alternatives: 

* Emphasizing the fact the implicit router does nothing: "null", "void", 
"no-op", "passive"
* Emphasizing the non-displacing aspect of the implicit router's function: 
"in-place", "in-situ", "static"


was (Author: steve_rowe):
bq. Another alternative to "manual" that came to mind was "custom".

To me "custom" implies configurable variability, which is not what's going on.

Some more alternatives: 

* Emphasizing the fact the implicit router does nothing: "null", "void", "no-op"
* Emphasizing the non-displacing aspect of the implicit router's function: 
"in-place", "in-situ", "static"

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Embeding distributed-solr in client-app without storing data

[Walter Underwood]

Does not make sense to me. It would do more queries from the client to the 
cluster, not fewer. And those HTTP request would probably be slower than the 
intra-cluster requests.

I expect the distributed portion of the query load is small compared to other 
CPU usage.

It adds complexity for no gain in performance. Maybe a slight loss.

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


> On Apr 19, 2017, at 6:32 AM, Mikhail Khludnev  wrote:
> 
> Hello, Dorian.
> I'm not sure about 1. But you can create EmbeddedSolrServer and add 
> "collection" parameter. It's what's done in 
> org.apache.solr.response.transform.SubQueryAugmenter [subquery]
> 
> On Wed, Apr 19, 2017 at 3:53 PM, Dorian Hoxha  > wrote:
> Hi friends,
> 
> Anybody has done this ? Reasons being: 1 less http-request when doing 
> distributed search. But also not storing data itself (like a 
> search-only-node). And the other nodes not caring about search-nodes.
> 
> Makes sense ?
> 
> Regards,
> Dorian
> 
> 
> 
> -- 
> Sincerely yours
> Mikhail Khludnev

[jira] [Commented] (LUCENE-7788) fail precommit on unparameterised log.trace messages

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7788:
--

I don't think the forbidden APIs can detect whether a String that is passed is 
a constant or constructed dynamically using {{+}} operators?

> fail precommit on unparameterised log.trace messages
> 
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7788.patch
>
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use 
> and once that is in place then this ticket's one-line change would be for 
> 'ant precommit' to reject any future unparameterised log.trace message use.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7789) replace & forbid "new FileInputStream" and "new FileOutputStream" with Files.newInputStream & Files.newOutputStream

[Hoss Man (JIRA)]

Hoss Man created LUCENE-7789:


 Summary: replace & forbid "new FileInputStream" and "new 
FileOutputStream" with Files.newInputStream & Files.newOutputStream
 Key: LUCENE-7789
 URL: https://issues.apache.org/jira/browse/LUCENE-7789
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Hoss Man


I haven't looked into the details of this much, but saw these links today and 
thought it would be worth opening a jira for discussion...

* https://dzone.com/articles/fileinputstream-fileoutputstream-considered-harmful
* https://issues.jenkins-ci.org/browse/JENKINS-42934
* https://bugs.openjdk.java.net/browse/JDK-8080225

The crux of the issue being that the "FileInputStream" and "FileOutputStream" 
classes have finalizer methods with GC overhead that can be avoided using 
Files.newInputStream and Files.newOutputStream in their place.

This seems like it would make these methods good candidates for forbidding in 
lucene/solr (if possible).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10522) Duplicate keys in "collations" object with JSON response format

[Nikita Pchelintsev (JIRA)]

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

Nikita Pchelintsev commented on SOLR-10522:
---

It seems that https://issues.apache.org/jira/browse/SOLR-9972 introduced this 
change

> Duplicate keys in "collations" object with JSON response format
> ---
>
> Key: SOLR-10522
> URL: https://issues.apache.org/jira/browse/SOLR-10522
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.5
>Reporter: Nikita Pchelintsev
>Priority: Minor
>
> After upgrading Solr 6.3 -> 6.5 I've noticed a change in how json response 
> writer outputs "collations" response key when spellchecking is enabled 
> (wt=json=arrarr)
> Solr 6.3:
> "collations":
> [
>   ["collation",{
>   "collationQuery":"the",
>   "hits":48,
>   "maxScore":"30.282",
>   "misspellingsAndCorrections":
>   [
> ["thea","the"]]}],
>   ["collation",{
>   "collationQuery":"tea",
>   "hits":3,
>   "maxScore":"2.936",
>   "misspellingsAndCorrections":
>   [
> ["thea","tea"]]}],
>   ...
> Solr 6.5:
> "collations":{
>   "collation":{
> "collationQuery":"the",
> "hits":43,
> "misspellingsAndCorrections":
> [
>   ["thea","the"]]},
>   "collation":{
> "collationQuery":"tea",
> "hits":3,
> "misspellingsAndCorrections":
> [
>   ["thea","tea"]]},
> ...
> Solr 6.5 outputs object instead of an array, and it has duplicate keys which 
> is not valid for JSON format.
> Any help is appreciated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10439) SchemaField.getNamedPropertyValues doesn't include 'large'

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10439:
-

Thanks for filing SOLR-10518.  It's a very thorough approach.

You are right that {{/schema/fieldtypes}} should include 'large' as well; 
_ugh_!   I tried {{/schema/dynamicfields}} and this one shows 'large' for me.  
I used {{showDefaults}} of course.

> SchemaField.getNamedPropertyValues doesn't include 'large'
> --
>
> Key: SOLR-10439
> URL: https://issues.apache.org/jira/browse/SOLR-10439
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 6.5.1, 6.6, master (7.0)
>
> Attachments: SOLR_10439.patch
>
>
> I just noticed SchemaField.getNamedPropertyValues refers to most/all of 
> FieldProperties constants. This is a maintenance problem; it'd be nice if 
> there were a test to ensure properties don't get forgotten.  {{LARGE}} was 
> forgotten.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10522) Duplicate keys in "collations" object with JSON response format

[Nikita Pchelintsev (JIRA)]

Nikita Pchelintsev created SOLR-10522:
-

 Summary: Duplicate keys in "collations" object with JSON response 
format
 Key: SOLR-10522
 URL: https://issues.apache.org/jira/browse/SOLR-10522
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: spellchecker
Affects Versions: 6.5
Reporter: Nikita Pchelintsev
Priority: Minor


After upgrading Solr 6.3 -> 6.5 I've noticed a change in how json response 
writer outputs "collations" response key when spellchecking is enabled 
(wt=json=arrarr)

Solr 6.3:

"collations":
[
  ["collation",{
  "collationQuery":"the",
  "hits":48,
  "maxScore":"30.282",
  "misspellingsAndCorrections":
  [
["thea","the"]]}],
  ["collation",{
  "collationQuery":"tea",
  "hits":3,
  "maxScore":"2.936",
  "misspellingsAndCorrections":
  [
["thea","tea"]]}],
  ...

Solr 6.5:

"collations":{
  "collation":{
"collationQuery":"the",
"hits":43,
"misspellingsAndCorrections":
[
  ["thea","the"]]},
  "collation":{
"collationQuery":"tea",
"hits":3,
"misspellingsAndCorrections":
[
  ["thea","tea"]]},
...

Solr 6.5 outputs object instead of an array, and it has duplicate keys which is 
not valid for JSON format.

Any help is appreciated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10523) Add Apache kerby jars in the Solr server classpath

[Hrishikesh Gadre (JIRA)]

Hrishikesh Gadre created SOLR-10523:
---

 Summary: Add Apache kerby jars in the Solr server classpath
 Key: SOLR-10523
 URL: https://issues.apache.org/jira/browse/SOLR-10523
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hrishikesh Gadre


Hadoop auth framework in Hadoop 3 (alpha2) requires Apache Kerby jars to be 
present in the Solr server classpath at runtime. Earlier these jars were 
configured only in the test scope (in solr/core/ivy.xml).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10524) Explore in-memory partitioning for processing Overseer queue messages

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-10524:
-

 Summary: Explore in-memory partitioning for processing Overseer 
queue messages
 Key: SOLR-10524
 URL: https://issues.apache.org/jira/browse/SOLR-10524
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson


There are several JIRAs (I'll link in a second) about trying to be more 
efficient about processing overseer messages as the overseer can become a 
bottleneck, especially with very large numbers of replicas in a cluster. One of 
the approaches mentioned near the end of SOLR-5872 (15-Mar) was to "read large 
no:of items say 1. put them into in memory buckets and feed them into 
overseer".

This JIRA is to break out that part of the discussion as it might be an easy 
win whereas "eliminating the Overseer queue" would be quite an undertaking.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Embeding distributed-solr in client-app without storing data

[Walter Underwood]

I know exactly how this works. MarkLogic can be configured with separate 
execute and data nodes. But in MarkLogic, the execute nodes can do a lot of 
work. The query may be a mix of indexed searching and “table scan” searching, 
all expressed in an XQuery program.

It does not make sense for Solr. The distributed portion of query execution is 
just not enough work to farm out to CPU intensive nodes.

It will mean more nodes to do the same work.

The execute nodes would need to be part of the cluster in order to get config 
updates. But they would not host shards. So now we need a new kind of node in 
the collection.

Lots more code, lots more testing, no benefit.

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


> On Apr 19, 2017, at 9:40 AM, Dorian Hoxha  wrote:
> 
> @Walter:
> 
> Think of it this way.
> 
> 1. Separate data-solr from merger-solr. So merger-solr has more cpu, while 
> data-solr has more ram (very simplistic).
> This way, you can also scale them separately. (es has something like 
> search-only-node)
> 
> 2. Second step is to join client-app with merger-solr. So you do 1 less hop. 
> This node doesn't have to lose the global-idf, query-cache or whatever 
> merger-only-solr currently does.
> If the client-app is just a frontend/proxy for solr, then should be better.
> 
> 3. The whole point is to have fewer, more powerful machines. And each 
> client-app should be able to saturate it's own embedded-solr.
> 
> Makes sense ?
> 
> On Wed, Apr 19, 2017 at 6:29 PM, Walter Underwood  > wrote:
> That is exactly what I thought you meant. Adds complexity with no benefit.
> 
> Now the merger needs to keep caches for global IDF. But those caches don’t 
> get the benefit of other requests to the same cluster.
> 
> I’m not sure if query result caches cache the results of distributed queries, 
> but if they do, then this approach looses that benefit too.
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org 
> http://observer.wunderwood.org/   (my blog)
> 
> 
>> On Apr 19, 2017, at 9:01 AM, Dorian Hoxha > > wrote:
>> 
>> @Walter
>> 
>> Usually you have: client-app --> random-solr-node(mergerer) --> each other 
>> node that has a shard
>> While what I want: client-app (mergerer is in same jvm) --> each other node 
>> that has a shard
>> 
>> Makes sense ?
>> 
>> On Wed, Apr 19, 2017 at 4:50 PM, Walter Underwood > > wrote:
>> Does not make sense to me. It would do more queries from the client to the 
>> cluster, not fewer. And those HTTP request would probably be slower than the 
>> intra-cluster requests.
>> 
>> I expect the distributed portion of the query load is small compared to 
>> other CPU usage.
>> 
>> It adds complexity for no gain in performance. Maybe a slight loss.
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org 
>> http://observer.wunderwood.org/   (my blog)
>> 
>> 
>>> On Apr 19, 2017, at 6:32 AM, Mikhail Khludnev >> > wrote:
>>> 
>>> Hello, Dorian.
>>> I'm not sure about 1. But you can create EmbeddedSolrServer and add 
>>> "collection" parameter. It's what's done in 
>>> org.apache.solr.response.transform.SubQueryAugmenter [subquery]
>>> 
>>> On Wed, Apr 19, 2017 at 3:53 PM, Dorian Hoxha >> > wrote:
>>> Hi friends,
>>> 
>>> Anybody has done this ? Reasons being: 1 less http-request when doing 
>>> distributed search. But also not storing data itself (like a 
>>> search-only-node). And the other nodes not caring about search-nodes.
>>> 
>>> Makes sense ?
>>> 
>>> Regards,
>>> Dorian
>>> 
>>> 
>>> 
>>> -- 
>>> Sincerely yours
>>> Mikhail Khludnev
>> 
>> 
> 
> 

Re: lucene-solr:master: SOLR-10439: 'large' was forgotten in /schema/fields?showDefaults=true

[David Smiley]

(I replied to your similar comment on the JIRA issue)

On Tue, Apr 18, 2017 at 7:05 PM Chris Hostetter 
wrote:

>
> David: doesn't this same bug affect /schema/fieldType ?
>
> Can't large="true" be specified on fieldType as a default for all fields
> that inherit from that type?
>
> Also: what about /schema/dynamicfields ?
>
>
>
>
> : Date: Tue, 18 Apr 2017 21:02:12 + (UTC)
> : From: dsmi...@apache.org
> : Reply-To: dev@lucene.apache.org
> : To: comm...@lucene.apache.org
> : Subject: lucene-solr:master: SOLR-10439: 'large' was forgotten in
> : /schema/fields?showDefaults=true
> :
> : Repository: lucene-solr
> : Updated Branches:
> :   refs/heads/master 10772121e -> 8347169ab
> :
> :
> : SOLR-10439: 'large' was forgotten in /schema/fields?showDefaults=true
> :
> :
> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> : Commit:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/8347169a
> : Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/8347169a
> : Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/8347169a
> :
> : Branch: refs/heads/master
> : Commit: 8347169ab3988e974e74c5e238dce9cc53d81f75
> : Parents: 1077212
> : Author: David Smiley 
> : Authored: Tue Apr 18 17:02:07 2017 -0400
> : Committer: David Smiley 
> : Committed: Tue Apr 18 17:02:07 2017 -0400
> :
> : --
> :  solr/CHANGES.txt  | 2 ++
> :  solr/core/src/java/org/apache/solr/schema/SchemaField.java| 1 +
> :  .../src/test/org/apache/solr/rest/schema/TestFieldResource.java   | 3
> ++-
> :  3 files changed, 5 insertions(+), 1 deletion(-)
> : --
> :
> :
> :
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/8347169a/solr/CHANGES.txt
> : --
> : diff --git a/solr/CHANGES.txt b/solr/CHANGES.txt
> : index b009951..e865311 100644
> : --- a/solr/CHANGES.txt
> : +++ b/solr/CHANGES.txt
> : @@ -294,6 +294,8 @@ Bug Fixes
> :
> :  * SOLR-10420: Solr 6.x leaking one SolrZkClient instance per second
> (Scott Blum, Cao Manh Dat, Markus Jelsma, Steve Rowe)
> :
> : +* SOLR-10439: The new 'large' attribute had been forgotten in
> /schema/fields?showDefaults=true
> : +
> :  ==  6.5.0 ==
> :
> :  Consult the LUCENE_CHANGES.txt file for additional, low level, changes
> in this release.
> :
> :
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/8347169a/solr/core/src/java/org/apache/solr/schema/SchemaField.java
> : --
> : diff --git a/solr/core/src/java/org/apache/solr/schema/SchemaField.java
> b/solr/core/src/java/org/apache/solr/schema/SchemaField.java
> : index d35d842..c2e8cca 100644
> : --- a/solr/core/src/java/org/apache/solr/schema/SchemaField.java
> : +++ b/solr/core/src/java/org/apache/solr/schema/SchemaField.java
> : @@ -336,6 +336,7 @@ public final class SchemaField extends
> FieldProperties implements IndexableField
> :properties.add(getPropertyName(OMIT_POSITIONS), omitPositions());
> :properties.add(getPropertyName(STORE_OFFSETS),
> storeOffsetsWithPositions());
> :properties.add(getPropertyName(MULTIVALUED), multiValued());
> : +  properties.add(getPropertyName(LARGE_FIELD), isLarge());
> :if (sortMissingFirst()) {
> :  properties.add(getPropertyName(SORT_MISSING_FIRST),
> sortMissingFirst());
> :} else if (sortMissingLast()) {
> :
> :
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/8347169a/solr/core/src/test/org/apache/solr/rest/schema/TestFieldResource.java
> : --
> : diff --git
> a/solr/core/src/test/org/apache/solr/rest/schema/TestFieldResource.java
> b/solr/core/src/test/org/apache/solr/rest/schema/TestFieldResource.java
> : index d591b9a..4f53609 100644
> : ---
> a/solr/core/src/test/org/apache/solr/rest/schema/TestFieldResource.java
> : +++
> b/solr/core/src/test/org/apache/solr/rest/schema/TestFieldResource.java
> : @@ -23,7 +23,7 @@ public class TestFieldResource extends
> SolrRestletTestBase {
> :public void testGetField() throws Exception {
> :
> assertQ("/schema/fields/test_postv?indent=on=xml=true",
> :  "count(/response/lst[@name='field']) = 1",
> : -"count(/response/lst[@name='field']/*) = 17",
> : +"count(/response/lst[@name='field']/*) = 18",
> :  "/response/lst[@name='field']/str[@name='name'] =
> 'test_postv'",
> :  "/response/lst[@name='field']/str[@name='type'] = 'text'",
> :  "/response/lst[@name='field']/bool[@name='indexed'] =
> 'true'",
> : @@ -38,6 +38,7 @@ public class TestFieldResource extends
> SolrRestletTestBase {
> :  

[jira] [Commented] (SOLR-10047) Mismatched Docvalue segments cause exception in Sorting/Facting; Uninvert per segment

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-10047:


Thanks Steve, I am able to reproduce this using this seed. The test commits 
three documents and relies on them not being merged into a single segment to 
verify the behavior of this patch works correctly. It seems like with this seed 
the merge policy is merging these three segments. 

What is the best way to setup this test to assure that no merges occur?

> Mismatched Docvalue segments cause exception in Sorting/Facting; Uninvert per 
> segment
> -
>
> Key: SOLR-10047
> URL: https://issues.apache.org/jira/browse/SOLR-10047
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Keith Laban
>Assignee: Shalin Shekhar Mangar
> Fix For: 6.6, master (7.0)
>
>
> The configuration of UninvertingReader in SolrIndexSearch creates a global 
> mapping for the directory for fields to uninvert. If docvalues are enabled on 
> a field the creation of a new segment will cause the query to fail when 
> faceting/sorting on the recently docvalue enabled field. This happens because 
> the UninvertingReader is configured globally across the entire directory, and 
> a single segment containing DVs for a field will incorrectly indicate that 
> all segments contain DVs.
> This patch addresses the incorrect behavior by determining the fields to be 
> uninverted on a per-segment basis.
> With the fix, it is still recommended that a reindexing occur as data loss 
> will when a DV and non-DV segment are merged, SOLR-10046 addresses this 
> behavior. This fix is to be a stop gap for the time between enabling 
> docvalues and the duration of a reindex. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Embeding distributed-solr in client-app without storing data

[Dorian Hoxha]

@Walter:

Think of it this way.

1. Separate data-solr from merger-solr. So merger-solr has more cpu, while
data-solr has more ram (very simplistic).
This way, you can also scale them separately. (es has something like
search-only-node)

2. Second step is to join client-app with merger-solr. So you do 1 less
hop. This node doesn't have to lose the global-idf, query-cache or whatever
merger-only-solr currently does.
If the client-app is just a frontend/proxy for solr, then should be better.

3. The whole point is to have fewer, more powerful machines. And each
client-app should be able to saturate it's own embedded-solr.

Makes sense ?

On Wed, Apr 19, 2017 at 6:29 PM, Walter Underwood 
wrote:

> That is exactly what I thought you meant. Adds complexity with no benefit.
>
> Now the merger needs to keep caches for global IDF. But those caches don’t
> get the benefit of other requests to the same cluster.
>
> I’m not sure if query result caches cache the results of distributed
> queries, but if they do, then this approach looses that benefit too.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>
> On Apr 19, 2017, at 9:01 AM, Dorian Hoxha  wrote:
>
> @Walter
>
> Usually you have: client-app --> random-solr-node(mergerer) --> each other
> node that has a shard
> While what I want: client-app (mergerer is in same jvm) --> each other
> node that has a shard
>
> Makes sense ?
>
> On Wed, Apr 19, 2017 at 4:50 PM, Walter Underwood 
> wrote:
>
>> Does not make sense to me. It would do more queries from the client to
>> the cluster, not fewer. And those HTTP request would probably be slower
>> than the intra-cluster requests.
>>
>> I expect the distributed portion of the query load is small compared to
>> other CPU usage.
>>
>> It adds complexity for no gain in performance. Maybe a slight loss.
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>>
>> On Apr 19, 2017, at 6:32 AM, Mikhail Khludnev  wrote:
>>
>> Hello, Dorian.
>> I'm not sure about 1. But you can create EmbeddedSolrServer and add
>> "collection" parameter. It's what's done in 
>> org.apache.solr.response.transform.SubQueryAugmenter
>> [subquery]
>>
>> On Wed, Apr 19, 2017 at 3:53 PM, Dorian Hoxha 
>> wrote:
>>
>>> Hi friends,
>>>
>>> Anybody has done this ? Reasons being: 1 less http-request when doing
>>> distributed search. But also not storing data itself (like a
>>> search-only-node). And the other nodes not caring about search-nodes.
>>>
>>> Makes sense ?
>>>
>>> Regards,
>>> Dorian
>>>
>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>>
>>
>>
>
>

Re: Issue with 6.5.1 RC2

[Joel Bernstein]

It appears that it's failing on verifying the SSL cert for
https://archive.apache.org/dist/lucene/java/.



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

On Wed, Apr 19, 2017 at 3:36 PM, Joel Bernstein  wrote:

> I started working on 6.5.1 RC2. I ran the following:
>
> python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local
> /tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
> I believe this is same basic command I used for RC1. But this time I got a
> new error. At first I thought it might be incorrect keystore password but I
> changed it and it is correct. Any thoughts what the issue is?
>
> Traceback (most recent call last):
>
>   File "dev-tools/scripts/buildAndPushRelease.py", line 313, in 
>
> main()
>
>   File "dev-tools/scripts/buildAndPushRelease.py", line 294, in main
>
> rev = prepare(c.root, c.version, c.key_id, c.key_password)
>
>   File "dev-tools/scripts/buildAndPushRelease.py", line 98, in prepare
>
> checkDOAPfiles(version)
>
>   File "dev-tools/scripts/buildAndPushRelease.py", line 143, in
> checkDOAPfiles
>
> distpage = load(url)
>
>   File "dev-tools/scripts/buildAndPushRelease.py", line 67, in load
>
> content = urllib.request.urlopen(urlString).read().decode('utf-8')
>
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 223, in urlopen
>
> return opener.open(url, data, timeout)
>
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 526, in open
>
> response = self._open(req, data)
>
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 544, in _open
>
> '_open', req)
>
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 504, in _call_chain
>
> result = func(*args)
>
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 1361, in https_open
>
> context=self._context, check_hostname=self._check_hostname)
>
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 1320, in do_open
>
> raise URLError(err)
>
> urllib.error.URLError:  certificate verify failed (_ssl.c:749)>
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>

[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[JIRA]

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

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

I like "manual", let's stick to the original plan :-) It says it all, there is 
nothing automatic about it, user/client has to *manually* take care of routing.

In my head, weirdly, even "explicit" would be better than "implicit", as the 
user/client needs to explicitly define routing, Solr won't do it for you ;-)

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-6630:


Anything is better than "implicit".  Explicit, Manual, and Custom are all good 
to me!

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-8762) DIH entity child=true should respond nested documents on debug

[gopikannan venugopalsamy (JIRA)]

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

gopikannan venugopalsamy updated SOLR-8762:
---
Attachment: SOLR-8762.patch

[~mkhludnev], Please check this patch, Added assert.

> DIH entity child=true should respond nested documents on debug
> --
>
> Key: SOLR-8762
> URL: https://issues.apache.org/jira/browse/SOLR-8762
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Reporter: Mikhail Khludnev
>Priority: Minor
>  Labels: newbie, newdev
> Attachments: SOLR-8762.patch
>
>
> Problem is described in 
> [comment|https://issues.apache.org/jira/browse/SOLR-5147?focusedCommentId=14744852=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14744852]
>  of SOLR-5147 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-8762) DIH entity child=true should respond nested documents on debug

[gopikannan venugopalsamy (JIRA)]

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

gopikannan venugopalsamy updated SOLR-8762:
---
Attachment: (was: SOLR-8762.patch)

> DIH entity child=true should respond nested documents on debug
> --
>
> Key: SOLR-8762
> URL: https://issues.apache.org/jira/browse/SOLR-8762
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Reporter: Mikhail Khludnev
>Priority: Minor
>  Labels: newbie, newdev
> Attachments: SOLR-8762.patch
>
>
> Problem is described in 
> [comment|https://issues.apache.org/jira/browse/SOLR-5147?focusedCommentId=14744852=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14744852]
>  of SOLR-5147 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Issue with 6.5.1 RC2

[Steve Rowe]

Yeah, that is a sucky part of this: you want to make modifications on the 
release branch, but you can’t test unless you commit (and push).

Another alternative: make modifications in another checkout, then invoke the 
script with from an unmodified source tree.

e.g.:

cd ..
cp -r lucene-solr lucene-solr-2 # assuming lucene-solr is your checkout dir
# edit lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py
cd lucene-solr
python3 -u ../lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py …

(a shorter form of that is to make a copy the script alone and invoke the 
modified version from your checkout) 

--
Steve
www.lucidworks.com

> On Apr 19, 2017, at 4:32 PM, Joel Bernstein  wrote:
> 
> Ha, that doesn't work either. Now I get this error:
> 
> RuntimeError: There are unpushed commits - "git log origin/branch_6_5.." 
> output is:
> 
> So, I'm going to have to push this out.
> 
> Let's first decide if this makes sense as the way forward.
> 
> 
> 
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> On Wed, Apr 19, 2017 at 4:28 PM, Joel Bernstein  wrote:
> Steve, when I change the script to turn off verification I get the following 
> error:
> RuntimeError: git clone is dirty:
> 
> So as part of the work around I think I'm going to have to commit locally and 
> then revert locally. Does that make sense to you as the way forward?
> 
> 
> 
> 
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> On Wed, Apr 19, 2017 at 4:24 PM, Alexandre Rafalovitch  
> wrote:
> Could it be anything to do with the fact that the signer is Semantic
> and they are being actively distrusted by - at least - Google:
> http://www.securityweek.com/google-stops-trusting-symantec-issued-certificates
> 
> Regards,
>Alex.
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
> 
> 
> On 19 April 2017 at 16:22, Joel Bernstein  wrote:
> > Ok, I'll turn off the cert verification. I wasn't sure if cert verification
> > was something that was integral to the process.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:18 PM, Steve Rowe  wrote:
> >>
> >> Hi Joel,
> >>
> >> Not sure why this is suddenly an issue - I guess “SNI”
> >>  has been enabled on
> >> archive.apache.org?
> >>
> >> Some useful info here (about a “requests” lib, AFAICT an alternative to
> >> urllib):
> >> 
> >>
> >> Short term, you could turn off certificate verification.  The bottom
> >> answer here uses the same lib as the script (urllib instead of urllib2,
> >> which is assumed in the other answers on the page), to turn off certificate
> >> verification:
> >>
> >>
> >> 
> >>
> >> --
> >> Steve
> >> www.lucidworks.com
> >>
> >> > On Apr 19, 2017, at 3:43 PM, Joel Bernstein  wrote:
> >> >
> >> > It appears that it's failing on verifying the SSL cert for
> >> > https://archive.apache.org/dist/lucene/java/.
> >> >
> >> >
> >> >
> >> > Joel Bernstein
> >> > http://joelsolr.blogspot.com/
> >> >
> >> > On Wed, Apr 19, 2017 at 3:36 PM, Joel Bernstein 
> >> > wrote:
> >> > I started working on 6.5.1 RC2. I ran the following:
> >> > python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local
> >> > /tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
> >> >
> >> > I believe this is same basic command I used for RC1. But this time I got
> >> > a new error. At first I thought it might be incorrect keystore password 
> >> > but
> >> > I changed it and it is correct. Any thoughts what the issue is?
> >> >
> >> > Traceback (most recent call last):
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 313, in 
> >> >
> >> > main()
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 294, in main
> >> >
> >> > rev = prepare(c.root, c.version, c.key_id, c.key_password)
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 98, in prepare
> >> >
> >> > checkDOAPfiles(version)
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 143, in
> >> > checkDOAPfiles
> >> >
> >> > distpage = load(url)
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 67, in load
> >> >
> >> > content = urllib.request.urlopen(urlString).read().decode('utf-8')
> >> >
> >> >   File
> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> >> > line 223, in urlopen
> >> >
> >> > return opener.open(url, data, timeout)
> >> >
> >> >   File
> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> >> > line 526, in open
> >> >
> >> > response = self._open(req, data)
> >> >
> >> >   

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Joel Bernstein]

Ok, I'll start the process.

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

On Wed, Apr 19, 2017 at 2:26 PM, David Smiley 
wrote:

> +1 works for me
>
> On Wed, Apr 19, 2017 at 8:06 AM Joel Bernstein  wrote:
>
>> Shall I cut an RC2 today?
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Tue, Apr 18, 2017 at 4:51 PM, Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> OK backported!
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> On Tue, Apr 18, 2017 at 4:41 PM, Michael McCandless <
>>> luc...@mikemccandless.com> wrote:
>>>
 Thanks for the suggestion David; I will backport LUCENE- shortly.

 Mike McCandless

 http://blog.mikemccandless.com

 On Tue, Apr 18, 2017 at 2:55 PM, David Smiley  wrote:

> Hmm; there are a lot of Solr bugs fixed in 6.6 but not yet 6.5.1... I
> wonder why others aren't back-porting their fixed bugs?
> Lucene has one: LUCENE-  Mike should it be ported to 6.5.1?
>
> On Tue, Apr 18, 2017 at 1:28 PM Joel Bernstein 
> wrote:
>
>> Sure
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Tue, Apr 18, 2017 at 1:20 PM, David Smiley <
>> david.w.smi...@gmail.com> wrote:
>>
>>> I've been sitting on these bug fixes (see below) in case there will
>>> be another RC and now it looks like there will be one.  Joel, shall I
>>> commit them to the release branch?
>>>
>>>
>>> On Mon, Apr 10, 2017 at 2:47 PM David Smiley <
>>> david.w.smi...@gmail.com> wrote:
>>>
 +1 SUCCESS! [0:48:18.176212]

 If there is a respin for any reason, I'd suggest including
 LUCENE-7769 (UH boost query) and SOLR-10439 ('large' and SchemaField)

 ~ David

 On Mon, Apr 10, 2017 at 2:07 PM Adrien Grand 
 wrote:

 +1 SUCCESS! [1:46:31.647123]

 Le lun. 10 avr. 2017 à 05:01, Joel Bernstein 
 a écrit :

 Please vote for release candidate 1 for Lucene/Solr 6.5.1The artifacts 
 can be downloaded from:

 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539

 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.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539

 Here's my +1

 SUCCESS! [0:40:54.049621]

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

 --
 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
 solrenterprisesearchserver.com

>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
>>> solrenterprisesearchserver.com
>>>
>>
>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>


>>>
>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>

[jira] [Closed] (SOLR-4381) Query-time multi-word synonym expansion

[JIRA]

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

Jan Høydahl closed SOLR-4381.
-
   Resolution: Won't Fix
Fix Version/s: (was: 6.0)
   (was: 4.9)

Closing as won't fix, since the new graph and sow stuff in SOLR-9185, 10343 
(https://lucidworks.com/2017/04/18/multi-word-synonyms-solr-adds-query-time-support/)
 provides an official solution, so the sedismax code will never land in Solr.

> Query-time multi-word synonym expansion
> ---
>
> Key: SOLR-4381
> URL: https://issues.apache.org/jira/browse/SOLR-4381
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Nolan Lawson
>Priority: Minor
>  Labels: multi-word, queryparser, synonyms
> Attachments: SOLR-4381-2.patch, SOLR-4381.patch
>
>
> This is an issue that seems to come up perennially.
> The [Solr 
> docs|http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory]
>  caution that index-time synonym expansion should be preferred to query-time 
> synonym expansion, due to the way multi-word synonyms are treated and how IDF 
> values can be boosted artificially. But query-time expansion should have huge 
> benefits, given that changes to the synonyms don't require re-indexing, the 
> index size stays the same, and the IDF values for the documents don't get 
> permanently altered.
> The proposed solution is to move the synonym expansion logic from the 
> analysis chain (either query- or index-type) and into a new QueryParser.  See 
> the attached patch for an implementation.
> The core Lucene functionality is untouched.  Instead, the EDismaxQParser is 
> extended, and synonym expansion is done on-the-fly.  Queries are parsed into 
> a lattice (i.e. all possible synonym combinations), while individual 
> components of the query are still handled by the EDismaxQParser itself.
> It's not an ideal solution by any stretch. But it's nice and self-contained, 
> so it invites experimentation and improvement.  And I think it fits in well 
> with the merry band of misfit query parsers, like {{func}} and {{frange}}.
> More details about this solution can be found in [this blog 
> post|http://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/] and 
> [the Github page for the 
> code|https://github.com/healthonnet/hon-lucene-synonyms].
> At the risk of tooting my own horn, I also think this patch sufficiently 
> fixes SOLR-3390 (highlighting problems with multi-word synonyms) and 
> LUCENE-4499 (better support for multi-word synonyms).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Issue with 6.5.1 RC2

[Joel Bernstein]

I started working on 6.5.1 RC2. I ran the following:

python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local
/tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
I believe this is same basic command I used for RC1. But this time I got a
new error. At first I thought it might be incorrect keystore password but I
changed it and it is correct. Any thoughts what the issue is?

Traceback (most recent call last):

  File "dev-tools/scripts/buildAndPushRelease.py", line 313, in 

main()

  File "dev-tools/scripts/buildAndPushRelease.py", line 294, in main

rev = prepare(c.root, c.version, c.key_id, c.key_password)

  File "dev-tools/scripts/buildAndPushRelease.py", line 98, in prepare

checkDOAPfiles(version)

  File "dev-tools/scripts/buildAndPushRelease.py", line 143, in
checkDOAPfiles

distpage = load(url)

  File "dev-tools/scripts/buildAndPushRelease.py", line 67, in load

content = urllib.request.urlopen(urlString).read().decode('utf-8')

  File
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
line 223, in urlopen

return opener.open(url, data, timeout)

  File
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
line 526, in open

response = self._open(req, data)

  File
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
line 544, in _open

'_open', req)

  File
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
line 504, in _call_chain

result = func(*args)

  File
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
line 1361, in https_open

context=self._context, check_hostname=self._check_hostname)

  File
"/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
line 1320, in do_open

raise URLError(err)

urllib.error.URLError: 



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

[jira] [Updated] (SOLR-10456) timeout-related setters should be deprecated in favor of SolrClientBuilder methods

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-10456:
---
Attachment: SOLR-10456.patch

Updates patch to remove conflicts with most recent master.

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10525) Stacked recovery requests can interfere with one another

[Mike Drob (JIRA)]

Mike Drob created SOLR-10525:


 Summary: Stacked recovery requests can interfere with one another
 Key: SOLR-10525
 URL: https://issues.apache.org/jira/browse/SOLR-10525
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Reporter: Mike Drob


https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310

Two issues with this code:

{code}
  boolean locked = recoveryLock.tryLock();
  try {
if (!locked) {
  if (recoveryWaiting.get() > 0) { // line 1
return;
  }
  recoveryWaiting.incrementAndGet(); // line 2
} else {
  recoveryWaiting.incrementAndGet();
  cancelRecovery(); // line 3
}
{code}

The {{cancelRecovery}} on line 3 call will only hit when there are no 
recoveries to actually cancel (since we got the lock that means there are no 
recoveries in progress). Instead it should be moved either to the either branch 
of the if, or outside after the if since we know we will be running a recovery 
at that point.

This code doesn't always prevent multiple requests from stacking. If there is a 
recovery running, but no recoveries currently waiting, multiple requests can 
check the count at line 1 before any of them will increment the count at line 2 
and thus all of them will hit the increment.

I don't have specific tests for this, but it's causing failures for me on my 
SOLR-9555 work in progress.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr issue #189: Jira/solr 6203

[cpoerschke]

Github user cpoerschke commented on the issue:

https://github.com/apache/lucene-solr/pull/189
  
Hi Judith - thanks for adding me to the collaborator list. I've added one 
more commit to the https://github.com/jitka18/lucene-solr/pull/1 request and 
would suggest something along the following lines as the next steps:
* to review https://github.com/jitka18/lucene-solr/pull/1 and if it looks 
good merge it into your jira/solr-6203 branch and/or add comments on the pull 
request
* to merge the latest master (at the time) into the jira/solr-6203 working 
branch
** this will give some merge conflicts that need to be resolved
** this will somewhat reduce the scope and complexity of the changes for 
the working branch since SOLR-10394 part-2 renames will be picked up from the 
latest master
* to see if new code duplication in DistributedQueryComponentCustomSortTest 
can be reduced further, this will not just reduce the amount of code but will 
(i think) also help with clarity i.e. what is being tested

How does that sound? Any questions, please let me know. - Christine


---
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] (SOLR-10394) search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort

[ASF GitHub Bot (JIRA)]

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

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

Github user cpoerschke commented on the issue:

https://github.com/apache/lucene-solr/pull/189
  
Hi Judith - thanks for adding me to the collaborator list. I've added one 
more commit to the https://github.com/jitka18/lucene-solr/pull/1 request and 
would suggest something along the following lines as the next steps:
* to review https://github.com/jitka18/lucene-solr/pull/1 and if it looks 
good merge it into your jira/solr-6203 branch and/or add comments on the pull 
request
* to merge the latest master (at the time) into the jira/solr-6203 working 
branch
** this will give some merge conflicts that need to be resolved
** this will somewhat reduce the scope and complexity of the changes for 
the working branch since SOLR-10394 part-2 renames will be picked up from the 
latest master
* to see if new code duplication in DistributedQueryComponentCustomSortTest 
can be reduced further, this will not just reduce the amount of code but will 
(i think) also help with clarity i.e. what is being tested

How does that sound? Any questions, please let me know. - Christine


> search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort
> -
>
> Key: SOLR-10394
> URL: https://issues.apache.org/jira/browse/SOLR-10394
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10394-part2.patch, SOLR-10394.patch
>
>
> The class is marked _@lucene.experimental_ and SOLR-9660 previously included 
> sortSpecWithinGroup to withinGroupSortSpec renaming for GroupSpecification; 
> the rename proposed here is in line with that.
> Motivation for the change is to reduce group-sort vs. within-group-sort 
> confusion, generally and specifically in SOLR-6203.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Issue with 6.5.1 RC2

[Alexandre Rafalovitch]

Could it be anything to do with the fact that the signer is Semantic
and they are being actively distrusted by - at least - Google:
http://www.securityweek.com/google-stops-trusting-symantec-issued-certificates

Regards,
   Alex.

http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 19 April 2017 at 16:22, Joel Bernstein  wrote:
> Ok, I'll turn off the cert verification. I wasn't sure if cert verification
> was something that was integral to the process.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Apr 19, 2017 at 4:18 PM, Steve Rowe  wrote:
>>
>> Hi Joel,
>>
>> Not sure why this is suddenly an issue - I guess “SNI”
>>  has been enabled on
>> archive.apache.org?
>>
>> Some useful info here (about a “requests” lib, AFAICT an alternative to
>> urllib):
>> 
>>
>> Short term, you could turn off certificate verification.  The bottom
>> answer here uses the same lib as the script (urllib instead of urllib2,
>> which is assumed in the other answers on the page), to turn off certificate
>> verification:
>>
>>
>> 
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On Apr 19, 2017, at 3:43 PM, Joel Bernstein  wrote:
>> >
>> > It appears that it's failing on verifying the SSL cert for
>> > https://archive.apache.org/dist/lucene/java/.
>> >
>> >
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> > On Wed, Apr 19, 2017 at 3:36 PM, Joel Bernstein 
>> > wrote:
>> > I started working on 6.5.1 RC2. I ran the following:
>> > python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local
>> > /tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
>> >
>> > I believe this is same basic command I used for RC1. But this time I got
>> > a new error. At first I thought it might be incorrect keystore password but
>> > I changed it and it is correct. Any thoughts what the issue is?
>> >
>> > Traceback (most recent call last):
>> >
>> >   File "dev-tools/scripts/buildAndPushRelease.py", line 313, in 
>> >
>> > main()
>> >
>> >   File "dev-tools/scripts/buildAndPushRelease.py", line 294, in main
>> >
>> > rev = prepare(c.root, c.version, c.key_id, c.key_password)
>> >
>> >   File "dev-tools/scripts/buildAndPushRelease.py", line 98, in prepare
>> >
>> > checkDOAPfiles(version)
>> >
>> >   File "dev-tools/scripts/buildAndPushRelease.py", line 143, in
>> > checkDOAPfiles
>> >
>> > distpage = load(url)
>> >
>> >   File "dev-tools/scripts/buildAndPushRelease.py", line 67, in load
>> >
>> > content = urllib.request.urlopen(urlString).read().decode('utf-8')
>> >
>> >   File
>> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>> > line 223, in urlopen
>> >
>> > return opener.open(url, data, timeout)
>> >
>> >   File
>> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>> > line 526, in open
>> >
>> > response = self._open(req, data)
>> >
>> >   File
>> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>> > line 544, in _open
>> >
>> > '_open', req)
>> >
>> >   File
>> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>> > line 504, in _call_chain
>> >
>> > result = func(*args)
>> >
>> >   File
>> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>> > line 1361, in https_open
>> >
>> > context=self._context, check_hostname=self._check_hostname)
>> >
>> >   File
>> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>> > line 1320, in do_open
>> >
>> > raise URLError(err)
>> >
>> > urllib.error.URLError: > > certificate verify failed (_ssl.c:749)>
>> >
>> >
>> >
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[jira] [Closed] (LUCENE-7068) Retrieve ranks

[Paul Elschot (JIRA)]

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

Paul Elschot closed LUCENE-7068.

Resolution: Won't Fix

Not enough interest

> Retrieve ranks
> --
>
> Key: LUCENE-7068
> URL: https://issues.apache.org/jira/browse/LUCENE-7068
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/other
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-7068.patch, LUCENE-7068.patch, LUCENE-7068.patch
>
>
> Join TopDocs by docs, keep the result ranks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-6630:


Thanks for the good discussion with names that I never thought of when I opened 
this issue.

Although the length of "userDefined" worries me a little bit, and the mixed 
case might lead to users mis-typing the configuration, I can only think of one 
real concern:  This wording implies that there is a configuration they can 
examine/edit that configures the routing definition.  Since my whole point was 
to eliminate ambiguity, I think that using that particular term is no better 
than "implicit".  I think that "custom" carries the same implication.

Some of the suggestions put forth by [~steve_rowe] are intriguing.  I really 
like "null" ... but that particular string is something you want to completely 
avoid in most programming environments, particularly Java.

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
TransactionLog, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:489)  
at org.apache.solr.core.SolrCore.(SolrCore.java:941)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:854)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:958)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:893)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:88)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:370)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:355)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:306)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:202)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:752)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:947)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:854)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:958)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:893)  at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19433/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testNoConfigSetExist

Error Message:
Error from server at https://127.0.0.1:45919/solr: Could not fully remove 
collection: addReplicaColl

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:45919/solr: Could not fully remove collection: 
addReplicaColl
at 
__randomizedtesting.SeedInfo.seed([F5C14D821BAAF4F3:A9F3F65B08AC3FAA]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:627)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:451)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:392)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1383)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:442)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.clearCluster(CollectionsAPIDistributedZkTest.java:113)
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$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Issue Comment Deleted] (SOLR-10394) search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-10394:
---
Comment: was deleted

(was: Github user cpoerschke commented on the issue:

https://github.com/apache/lucene-solr/pull/189
  
Hi Judith - thanks for adding me to the collaborator list. I've added one 
more commit to the https://github.com/jitka18/lucene-solr/pull/1 request and 
would suggest something along the following lines as the next steps:
* to review https://github.com/jitka18/lucene-solr/pull/1 and if it looks 
good merge it into your jira/solr-6203 branch and/or add comments on the pull 
request
* to merge the latest master (at the time) into the jira/solr-6203 working 
branch
** this will give some merge conflicts that need to be resolved
** this will somewhat reduce the scope and complexity of the changes for 
the working branch since SOLR-10394 part-2 renames will be picked up from the 
latest master
* to see if new code duplication in DistributedQueryComponentCustomSortTest 
can be reduced further, this will not just reduce the amount of code but will 
(i think) also help with clarity i.e. what is being tested

How does that sound? Any questions, please let me know. - Christine
)

> search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort
> -
>
> Key: SOLR-10394
> URL: https://issues.apache.org/jira/browse/SOLR-10394
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10394-part2.patch, SOLR-10394.patch
>
>
> The class is marked _@lucene.experimental_ and SOLR-9660 previously included 
> sortSpecWithinGroup to withinGroupSortSpec renaming for GroupSpecification; 
> the rename proposed here is in line with that.
> Motivation for the change is to reduce group-sort vs. within-group-sort 
> confusion, generally and specifically in SOLR-6203.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (LUCENE-7602) Fix compiler warnings for ant clean compile

[Paul Elschot (JIRA)]

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

Paul Elschot resolved LUCENE-7602.
--
Resolution: Won't Fix

Not enough interest

> Fix compiler warnings for ant clean compile
> ---
>
> Key: LUCENE-7602
> URL: https://issues.apache.org/jira/browse/LUCENE-7602
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>Priority: Minor
>  Labels: build
> Fix For: trunk
>
> Attachments: LUCENE-7602-ContextMap-lucene.patch, 
> LUCENE-7602-ContextMap-solr.patch, LUCENE-7602.patch, LUCENE-7602.patch, 
> LUCENE-7602.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Issue with 6.5.1 RC2

[Joel Bernstein]

Ha, that doesn't work either. Now I get this error:

RuntimeError: There are unpushed commits - "git log origin/branch_6_5.."
output is:

So, I'm going to have to push this out.

Let's first decide if this makes sense as the way forward.



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

On Wed, Apr 19, 2017 at 4:28 PM, Joel Bernstein  wrote:

> Steve, when I change the script to turn off verification I get the
> following error:
>
> RuntimeError: git clone is dirty:
>
> So as part of the work around I think I'm going to have to commit locally
> and then revert locally. Does that make sense to you as the way forward?
>
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, Apr 19, 2017 at 4:24 PM, Alexandre Rafalovitch  > wrote:
>
>> Could it be anything to do with the fact that the signer is Semantic
>> and they are being actively distrusted by - at least - Google:
>> http://www.securityweek.com/google-stops-trusting-symantec-
>> issued-certificates
>>
>> Regards,
>>Alex.
>> 
>> http://www.solr-start.com/ - Resources for Solr users, new and
>> experienced
>>
>>
>> On 19 April 2017 at 16:22, Joel Bernstein  wrote:
>> > Ok, I'll turn off the cert verification. I wasn't sure if cert
>> verification
>> > was something that was integral to the process.
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> > On Wed, Apr 19, 2017 at 4:18 PM, Steve Rowe  wrote:
>> >>
>> >> Hi Joel,
>> >>
>> >> Not sure why this is suddenly an issue - I guess “SNI”
>> >>  has been
>> enabled on
>> >> archive.apache.org?
>> >>
>> >> Some useful info here (about a “requests” lib, AFAICT an alternative to
>> >> urllib):
>> >> > at-are-hostname-doesn-t-match-errors>
>> >>
>> >> Short term, you could turn off certificate verification.  The bottom
>> >> answer here uses the same lib as the script (urllib instead of urllib2,
>> >> which is assumed in the other answers on the page), to turn off
>> certificate
>> >> verification:
>> >>
>> >>
>> >> > certicate-validation-urllib2>
>> >>
>> >> --
>> >> Steve
>> >> www.lucidworks.com
>> >>
>> >> > On Apr 19, 2017, at 3:43 PM, Joel Bernstein 
>> wrote:
>> >> >
>> >> > It appears that it's failing on verifying the SSL cert for
>> >> > https://archive.apache.org/dist/lucene/java/.
>> >> >
>> >> >
>> >> >
>> >> > Joel Bernstein
>> >> > http://joelsolr.blogspot.com/
>> >> >
>> >> > On Wed, Apr 19, 2017 at 3:36 PM, Joel Bernstein 
>> >> > wrote:
>> >> > I started working on 6.5.1 RC2. I ran the following:
>> >> > python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local
>> >> > /tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
>> >> >
>> >> > I believe this is same basic command I used for RC1. But this time I
>> got
>> >> > a new error. At first I thought it might be incorrect keystore
>> password but
>> >> > I changed it and it is correct. Any thoughts what the issue is?
>> >> >
>> >> > Traceback (most recent call last):
>> >> >
>> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 313, in
>> 
>> >> >
>> >> > main()
>> >> >
>> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 294, in main
>> >> >
>> >> > rev = prepare(c.root, c.version, c.key_id, c.key_password)
>> >> >
>> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 98, in
>> prepare
>> >> >
>> >> > checkDOAPfiles(version)
>> >> >
>> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 143, in
>> >> > checkDOAPfiles
>> >> >
>> >> > distpage = load(url)
>> >> >
>> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 67, in load
>> >> >
>> >> > content = urllib.request.urlopen(urlStri
>> ng).read().decode('utf-8')
>> >> >
>> >> >   File
>> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/pytho
>> n3.6/urllib/request.py",
>> >> > line 223, in urlopen
>> >> >
>> >> > return opener.open(url, data, timeout)
>> >> >
>> >> >   File
>> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/pytho
>> n3.6/urllib/request.py",
>> >> > line 526, in open
>> >> >
>> >> > response = self._open(req, data)
>> >> >
>> >> >   File
>> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/pytho
>> n3.6/urllib/request.py",
>> >> > line 544, in _open
>> >> >
>> >> > '_open', req)
>> >> >
>> >> >   File
>> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/pytho
>> n3.6/urllib/request.py",
>> >> > line 504, in _call_chain
>> >> >
>> >> > result = func(*args)
>> >> >
>> >> >   File
>> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/pytho
>> n3.6/urllib/request.py",
>> >> > line 1361, in https_open
>> >> >
>> >> > context=self._context, check_hostname=self._check_hostname)
>> >> >
>> >> >   File
>> >> > 

[jira] [Closed] (LUCENE-7471) Simplify NearSpansOrdered

[Paul Elschot (JIRA)]

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

Paul Elschot closed LUCENE-7471.

Resolution: Duplicate

Duplicate of LUCENE-7715, fixed and closed.

> Simplify NearSpansOrdered
> -
>
> Key: LUCENE-7471
> URL: https://issues.apache.org/jira/browse/LUCENE-7471
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-7471.patch
>
>
> Extend the span positions priority queue, remove SpansCell.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (SOLR-5379) Query-time multi-word synonym expansion

[JIRA]

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

Jan Høydahl closed SOLR-5379.
-
   Resolution: Duplicate
Fix Version/s: (was: 6.0)
   (was: 4.9)

Closing as duplicate since SOLR-9185 (sow) and SOLR-10343 (Graph) now provides 
the official solution to this issue. See 
https://lucidworks.com/2017/04/18/multi-word-synonyms-solr-adds-query-time-support/

> Query-time multi-word synonym expansion
> ---
>
> Key: SOLR-5379
> URL: https://issues.apache.org/jira/browse/SOLR-5379
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Tien Nguyen Manh
>  Labels: multi-word, queryparser, synonym
> Attachments: conf-test-files-4_8_1.patch, quoted-4_8_1.patch, 
> quoted.patch, solr-5379-version-4.10.3.patch, synonym-expander-4_8_1.patch, 
> synonym-expander.patch
>
>
> While dealing with synonym at query time, solr failed to work with multi-word 
> synonyms due to some reasons:
> - First the lucene queryparser tokenizes user query by space so it split 
> multi-word term into two terms before feeding to synonym filter, so synonym 
> filter can't recognized multi-word term to do expansion
> - Second, if synonym filter expand into multiple terms which contains 
> multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to 
> handle synonyms. But MultiPhraseQuery don't work with term have different 
> number of words.
> For the first one, we can extend quoted all multi-word synonym in user query 
> so that lucene queryparser don't split it. There are a jira task related to 
> this one https://issues.apache.org/jira/browse/LUCENE-2605.
> For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery 
> SHOULD which contains multiple PhraseQuery in case tokens stream have 
> multi-word synonym.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Issue with 6.5.1 RC2

[Steve Rowe]

Hi Joel,

Not sure why this is suddenly an issue - I guess “SNI” 
 has been enabled on 
archive.apache.org? 

Some useful info here (about a “requests” lib, AFAICT an alternative to 
urllib): 


Short term, you could turn off certificate verification.  The bottom answer 
here uses the same lib as the script (urllib instead of urllib2, which is 
assumed in the other answers on the page), to turn off certificate verification:



--
Steve
www.lucidworks.com

> On Apr 19, 2017, at 3:43 PM, Joel Bernstein  wrote:
> 
> It appears that it's failing on verifying the SSL cert for 
> https://archive.apache.org/dist/lucene/java/.
> 
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> On Wed, Apr 19, 2017 at 3:36 PM, Joel Bernstein  wrote:
> I started working on 6.5.1 RC2. I ran the following:
> python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local 
> /tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
> 
> I believe this is same basic command I used for RC1. But this time I got a 
> new error. At first I thought it might be incorrect keystore password but I 
> changed it and it is correct. Any thoughts what the issue is?
> 
> Traceback (most recent call last):
> 
>   File "dev-tools/scripts/buildAndPushRelease.py", line 313, in 
> 
> main()
> 
>   File "dev-tools/scripts/buildAndPushRelease.py", line 294, in main
> 
> rev = prepare(c.root, c.version, c.key_id, c.key_password)
> 
>   File "dev-tools/scripts/buildAndPushRelease.py", line 98, in prepare
> 
> checkDOAPfiles(version)
> 
>   File "dev-tools/scripts/buildAndPushRelease.py", line 143, in checkDOAPfiles
> 
> distpage = load(url)
> 
>   File "dev-tools/scripts/buildAndPushRelease.py", line 67, in load
> 
> content = urllib.request.urlopen(urlString).read().decode('utf-8')
> 
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>  line 223, in urlopen
> 
> return opener.open(url, data, timeout)
> 
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>  line 526, in open
> 
> response = self._open(req, data)
> 
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>  line 544, in _open
> 
> '_open', req)
> 
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>  line 504, in _call_chain
> 
> result = func(*args)
> 
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>  line 1361, in https_open
> 
> context=self._context, check_hostname=self._check_hostname)
> 
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
>  line 1320, in do_open
> 
> raise URLError(err)
> 
> urllib.error.URLError:  certificate verify failed (_ssl.c:749)>
> 
> 
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 


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

Re: Issue with 6.5.1 RC2

[Joel Bernstein]

Ok, I'll turn off the cert verification. I wasn't sure if cert verification
was something that was integral to the process.

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

On Wed, Apr 19, 2017 at 4:18 PM, Steve Rowe  wrote:

> Hi Joel,
>
> Not sure why this is suddenly an issue - I guess “SNI” <
> https://en.wikipedia.org/wiki/Server_Name_Indication> has been enabled on
> archive.apache.org?
>
> Some useful info here (about a “requests” lib, AFAICT an alternative to
> urllib):  what-are-hostname-doesn-t-match-errors>
>
> Short term, you could turn off certificate verification.  The bottom
> answer here uses the same lib as the script (urllib instead of urllib2,
> which is assumed in the other answers on the page), to turn off certificate
> verification:
>
>  ignore-certicate-validation-urllib2>
>
> --
> Steve
> www.lucidworks.com
>
> > On Apr 19, 2017, at 3:43 PM, Joel Bernstein  wrote:
> >
> > It appears that it's failing on verifying the SSL cert for
> https://archive.apache.org/dist/lucene/java/.
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 3:36 PM, Joel Bernstein 
> wrote:
> > I started working on 6.5.1 RC2. I ran the following:
> > python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local
> /tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
> >
> > I believe this is same basic command I used for RC1. But this time I got
> a new error. At first I thought it might be incorrect keystore password but
> I changed it and it is correct. Any thoughts what the issue is?
> >
> > Traceback (most recent call last):
> >
> >   File "dev-tools/scripts/buildAndPushRelease.py", line 313, in 
> >
> > main()
> >
> >   File "dev-tools/scripts/buildAndPushRelease.py", line 294, in main
> >
> > rev = prepare(c.root, c.version, c.key_id, c.key_password)
> >
> >   File "dev-tools/scripts/buildAndPushRelease.py", line 98, in prepare
> >
> > checkDOAPfiles(version)
> >
> >   File "dev-tools/scripts/buildAndPushRelease.py", line 143, in
> checkDOAPfiles
> >
> > distpage = load(url)
> >
> >   File "dev-tools/scripts/buildAndPushRelease.py", line 67, in load
> >
> > content = urllib.request.urlopen(urlString).read().decode('utf-8')
> >
> >   File 
> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 223, in urlopen
> >
> > return opener.open(url, data, timeout)
> >
> >   File 
> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 526, in open
> >
> > response = self._open(req, data)
> >
> >   File 
> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 544, in _open
> >
> > '_open', req)
> >
> >   File 
> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 504, in _call_chain
> >
> > result = func(*args)
> >
> >   File 
> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 1361, in https_open
> >
> > context=self._context, check_hostname=self._check_hostname)
> >
> >   File 
> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py",
> line 1320, in do_open
> >
> > raise URLError(err)
> >
> > urllib.error.URLError:  certificate verify failed (_ssl.c:749)>
> >
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Resolved] (SOLR-5127) Allow multiple wildcards in hl.fl

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-5127.
---
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.6

Thanks everyone!

> Allow multiple wildcards in hl.fl
> -
>
> Key: SOLR-5127
> URL: https://issues.apache.org/jira/browse/SOLR-5127
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 3.6.1, 4.4
>Reporter: Sven-S. Porst
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: highlight-wildcards.patch, SOLR-5127.patch, 
> SOLR-5127.patch, SOLR-5127.patch
>
>
> When a wildcard is present in the hl.fl field, the field is not split up at 
> commas/spaces into components. As a consequence settings like 
> hl.fl=*_highlight,*_data do not work.
> Splitting the string first and evaluating wildcards on each component 
> afterwards would be more powerful and consistent with the documentation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10394) search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-10394.

   Resolution: Fixed
Fix Version/s: master (7.0)
   6.6

> search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort
> -
>
> Key: SOLR-10394
> URL: https://issues.apache.org/jira/browse/SOLR-10394
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10394-part2.patch, SOLR-10394.patch
>
>
> The class is marked _@lucene.experimental_ and SOLR-9660 previously included 
> sortSpecWithinGroup to withinGroupSortSpec renaming for GroupSpecification; 
> the rename proposed here is in line with that.
> Motivation for the change is to reduce group-sort vs. within-group-sort 
> confusion, generally and specifically in SOLR-6203.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10283) SolrFeature fails to reject searches with missing efi (if used by fq)

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-10283.

Resolution: Fixed

> SolrFeature fails to reject searches with missing efi (if used by fq)
> -
>
> Key: SOLR-10283
> URL: https://issues.apache.org/jira/browse/SOLR-10283
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.4, 6.4.1, 6.4.2
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: master (7.0), 6.5
>
> Attachments: SOLR-10283.patch, SOLR-10283.patch
>
>
> My intention had been to update the Solr Reference Guide's Learning To Rank 
> section w.r.t. External Feature Information i.e. 
> https://cwiki.apache.org/confluence/display/solr/Learning+To+Rank#LearningToRank-ExternalFeatureInformation
>  based on the 
> https://lists.apache.org/thread.html/17547c1487067804077b1933ccde28d68841ec1694f6776c5682f28e@%3Csolr-user.lucene.apache.org%3E
>  user mailing list thread.
> In the process I noticed that configuring a feature such as this
> {code}
> {
>   "store" : "myEfiFeatureStore",
>   "name" : "isPreferredManufacturer",
>   "class" : "org.apache.solr.ltr.feature.SolrFeature",
>   "params" : { "fq" : [ "{!field f=manu}${preferredManufacturer}" ] }
> }
> {code}
> and then _not_ passing {{efi.preferredManufacturer=something}} is _not_ 
> rejected and instead a score of 1.0 is returned for the feature.
> This seems unexpected i.e. a bug.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Issue with 6.5.1 RC2

[Joel Bernstein]

Steve, when I change the script to turn off verification I get the
following error:

RuntimeError: git clone is dirty:

So as part of the work around I think I'm going to have to commit locally
and then revert locally. Does that make sense to you as the way forward?




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

On Wed, Apr 19, 2017 at 4:24 PM, Alexandre Rafalovitch 
wrote:

> Could it be anything to do with the fact that the signer is Semantic
> and they are being actively distrusted by - at least - Google:
> http://www.securityweek.com/google-stops-trusting-
> symantec-issued-certificates
>
> Regards,
>Alex.
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>
>
> On 19 April 2017 at 16:22, Joel Bernstein  wrote:
> > Ok, I'll turn off the cert verification. I wasn't sure if cert
> verification
> > was something that was integral to the process.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:18 PM, Steve Rowe  wrote:
> >>
> >> Hi Joel,
> >>
> >> Not sure why this is suddenly an issue - I guess “SNI”
> >>  has been
> enabled on
> >> archive.apache.org?
> >>
> >> Some useful info here (about a “requests” lib, AFAICT an alternative to
> >> urllib):
> >>  what-are-hostname-doesn-t-match-errors>
> >>
> >> Short term, you could turn off certificate verification.  The bottom
> >> answer here uses the same lib as the script (urllib instead of urllib2,
> >> which is assumed in the other answers on the page), to turn off
> certificate
> >> verification:
> >>
> >>
> >>  ignore-certicate-validation-urllib2>
> >>
> >> --
> >> Steve
> >> www.lucidworks.com
> >>
> >> > On Apr 19, 2017, at 3:43 PM, Joel Bernstein 
> wrote:
> >> >
> >> > It appears that it's failing on verifying the SSL cert for
> >> > https://archive.apache.org/dist/lucene/java/.
> >> >
> >> >
> >> >
> >> > Joel Bernstein
> >> > http://joelsolr.blogspot.com/
> >> >
> >> > On Wed, Apr 19, 2017 at 3:36 PM, Joel Bernstein 
> >> > wrote:
> >> > I started working on 6.5.1 RC2. I ran the following:
> >> > python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local
> >> > /tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
> >> >
> >> > I believe this is same basic command I used for RC1. But this time I
> got
> >> > a new error. At first I thought it might be incorrect keystore
> password but
> >> > I changed it and it is correct. Any thoughts what the issue is?
> >> >
> >> > Traceback (most recent call last):
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 313, in
> 
> >> >
> >> > main()
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 294, in main
> >> >
> >> > rev = prepare(c.root, c.version, c.key_id, c.key_password)
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 98, in
> prepare
> >> >
> >> > checkDOAPfiles(version)
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 143, in
> >> > checkDOAPfiles
> >> >
> >> > distpage = load(url)
> >> >
> >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 67, in load
> >> >
> >> > content = urllib.request.urlopen(urlString).read().decode('utf-
> 8')
> >> >
> >> >   File
> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/urllib/request.py",
> >> > line 223, in urlopen
> >> >
> >> > return opener.open(url, data, timeout)
> >> >
> >> >   File
> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/urllib/request.py",
> >> > line 526, in open
> >> >
> >> > response = self._open(req, data)
> >> >
> >> >   File
> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/urllib/request.py",
> >> > line 544, in _open
> >> >
> >> > '_open', req)
> >> >
> >> >   File
> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/urllib/request.py",
> >> > line 504, in _call_chain
> >> >
> >> > result = func(*args)
> >> >
> >> >   File
> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/urllib/request.py",
> >> > line 1361, in https_open
> >> >
> >> > context=self._context, check_hostname=self._check_hostname)
> >> >
> >> >   File
> >> > "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/urllib/request.py",
> >> > line 1320, in do_open
> >> >
> >> > raise URLError(err)
> >> >
> >> > urllib.error.URLError:  >> > certificate verify failed (_ssl.c:749)>
> >> >
> >> >
> >> >
> >> >
> >> > Joel Bernstein
> >> > http://joelsolr.blogspot.com/
> >> >
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: 

[jira] [Closed] (LUCENE-5687) Split off SinkTokenStream from TeeSinkTokenFilter (was add PrefillTokenStream ...)

[Paul Elschot (JIRA)]

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

Paul Elschot closed LUCENE-5687.

Resolution: Won't Fix

Not enough interest

> Split off SinkTokenStream from TeeSinkTokenFilter (was add PrefillTokenStream 
> ...)
> --
>
> Key: LUCENE-5687
> URL: https://issues.apache.org/jira/browse/LUCENE-5687
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 4.9
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: 4.9
>
> Attachments: LUCENE-5687.patch, LUCENE-5687.patch, LUCENE-5687.patch, 
> LUCENE-5687.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10526) facet.heatmap doesn't honor fq tag exclusion in distributed search

[David Smiley (JIRA)]

David Smiley created SOLR-10526:
---

 Summary: facet.heatmap doesn't honor fq tag exclusion in 
distributed search
 Key: SOLR-10526
 URL: https://issues.apache.org/jira/browse/SOLR-10526
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: faceting
Reporter: David Smiley
Assignee: David Smiley


Excluding a tagged filter query on a heatmap facet doesn't work in distributed 
(sharded) mode -- it's effectively ignored.  Aside from being a bug in 
semantics (more counts should be returned), it can also thwart an optimization 
of SOLR-10499.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10394) search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort

[ASF GitHub Bot (JIRA)]

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

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

Github user jitka18 commented on the issue:

https://github.com/apache/lucene-solr/pull/189
  
Hi, Christine.  I accepted your pull request and will update my branch from
the  master later today.   Will also take a look at the tests in DQCCST.

Thanks,
Judith

On Wed, Apr 19, 2017 at 1:19 PM, Christine Poerschke <
notificati...@github.com> wrote:

> Hi Judith - thanks for adding me to the collaborator list. I've added one
> more commit to the jitka18#1
>  request and would suggest
> something along the following lines as the next steps:
>
>- to review jitka18#1 
>and if it looks good merge it into your jira/solr-6203 branch and/or 
add
>comments on the pull request
>- to merge the latest master (at the time) into the jira/solr-6203
>working branch
>** this will give some merge conflicts that need to be resolved
>** this will somewhat reduce the scope and complexity of the changes
>for the working branch since SOLR-10394 part-2 renames will be picked 
up
>from the latest master
>- to see if new code duplication in 
DistributedQueryComponentCustomSortTest
>can be reduced further, this will not just reduce the amount of code 
but
>will (i think) also help with clarity i.e. what is being tested
>
> How does that sound? Any questions, please let me know. - Christine
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 

> .
>



> search.grouping.Command rename: getSortWithinGroup --> getWithinGroupSort
> -
>
> Key: SOLR-10394
> URL: https://issues.apache.org/jira/browse/SOLR-10394
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10394-part2.patch, SOLR-10394.patch
>
>
> The class is marked _@lucene.experimental_ and SOLR-9660 previously included 
> sortSpecWithinGroup to withinGroupSortSpec renaming for GroupSpecification; 
> the rename proposed here is in line with that.
> Motivation for the change is to reduce group-sort vs. within-group-sort 
> confusion, generally and specifically in SOLR-6203.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10525) Stacked recovery requests can interfere with one another

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-10525 at 4/19/17 9:33 PM:
-

Don't know if I answered Shalin's comment, but I've answered others about it. 
I'm sure that is part of SOLR-8702 being filed, but seems no one has worked on 
it. The current strategy was easy to get to from where we were, and still very 
fast.


was (Author: markrmil...@gmail.com):
Don't know if I answered Shalin's comment, but I've answered others about it. 
I'm sure that is part of SOLR-8702 being filed, but seems no one has worked on 
it. The current strategy was easy to get to from where were, and still very 
fast.

> Stacked recovery requests can interfere with one another
> 
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
> Attachments: SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
>   boolean locked = recoveryLock.tryLock();
>   try {
> if (!locked) {
>   if (recoveryWaiting.get() > 0) { // line 1
> return;
>   }
>   recoveryWaiting.incrementAndGet(); // line 2
> } else {
>   recoveryWaiting.incrementAndGet();
>   cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no 
> recoveries to actually cancel (since we got the lock that means there are no 
> recoveries in progress). Instead it should be moved either to the either 
> branch of the if, or outside after the if since we know we will be running a 
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is 
> a recovery running, but no recoveries currently waiting, multiple requests 
> can check the count at line 1 before any of them will increment the count at 
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my 
> SOLR-9555 work in progress.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Issue with 6.5.1 RC2

[Joel Bernstein]

I'll push out the changes and then revert. Hopefully the changes will do
the trick after they've been pushed.

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

On Wed, Apr 19, 2017 at 4:37 PM, Steve Rowe  wrote:

> Yeah, that is a sucky part of this: you want to make modifications on the
> release branch, but you can’t test unless you commit (and push).
>
> Another alternative: make modifications in another checkout, then invoke
> the script with from an unmodified source tree.
>
> e.g.:
>
> cd ..
> cp -r lucene-solr lucene-solr-2 # assuming lucene-solr is your checkout dir
> # edit lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py
> cd lucene-solr
> python3 -u ../lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py …
>
> (a shorter form of that is to make a copy the script alone and invoke the
> modified version from your checkout)
>
> --
> Steve
> www.lucidworks.com
>
> > On Apr 19, 2017, at 4:32 PM, Joel Bernstein  wrote:
> >
> > Ha, that doesn't work either. Now I get this error:
> >
> > RuntimeError: There are unpushed commits - "git log origin/branch_6_5.."
> output is:
> >
> > So, I'm going to have to push this out.
> >
> > Let's first decide if this makes sense as the way forward.
> >
> >
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:28 PM, Joel Bernstein 
> wrote:
> > Steve, when I change the script to turn off verification I get the
> following error:
> > RuntimeError: git clone is dirty:
> >
> > So as part of the work around I think I'm going to have to commit
> locally and then revert locally. Does that make sense to you as the way
> forward?
> >
> >
> >
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:24 PM, Alexandre Rafalovitch <
> arafa...@gmail.com> wrote:
> > Could it be anything to do with the fact that the signer is Semantic
> > and they are being actively distrusted by - at least - Google:
> > http://www.securityweek.com/google-stops-trusting-
> symantec-issued-certificates
> >
> > Regards,
> >Alex.
> > 
> > http://www.solr-start.com/ - Resources for Solr users, new and
> experienced
> >
> >
> > On 19 April 2017 at 16:22, Joel Bernstein  wrote:
> > > Ok, I'll turn off the cert verification. I wasn't sure if cert
> verification
> > > was something that was integral to the process.
> > >
> > > Joel Bernstein
> > > http://joelsolr.blogspot.com/
> > >
> > > On Wed, Apr 19, 2017 at 4:18 PM, Steve Rowe  wrote:
> > >>
> > >> Hi Joel,
> > >>
> > >> Not sure why this is suddenly an issue - I guess “SNI”
> > >>  has been
> enabled on
> > >> archive.apache.org?
> > >>
> > >> Some useful info here (about a “requests” lib, AFAICT an alternative
> to
> > >> urllib):
> > >>  what-are-hostname-doesn-t-match-errors>
> > >>
> > >> Short term, you could turn off certificate verification.  The bottom
> > >> answer here uses the same lib as the script (urllib instead of
> urllib2,
> > >> which is assumed in the other answers on the page), to turn off
> certificate
> > >> verification:
> > >>
> > >>
> > >>  ignore-certicate-validation-urllib2>
> > >>
> > >> --
> > >> Steve
> > >> www.lucidworks.com
> > >>
> > >> > On Apr 19, 2017, at 3:43 PM, Joel Bernstein 
> wrote:
> > >> >
> > >> > It appears that it's failing on verifying the SSL cert for
> > >> > https://archive.apache.org/dist/lucene/java/.
> > >> >
> > >> >
> > >> >
> > >> > Joel Bernstein
> > >> > http://joelsolr.blogspot.com/
> > >> >
> > >> > On Wed, Apr 19, 2017 at 3:36 PM, Joel Bernstein  >
> > >> > wrote:
> > >> > I started working on 6.5.1 RC2. I ran the following:
> > >> > python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local
> > >> > /tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
> > >> >
> > >> > I believe this is same basic command I used for RC1. But this time
> I got
> > >> > a new error. At first I thought it might be incorrect keystore
> password but
> > >> > I changed it and it is correct. Any thoughts what the issue is?
> > >> >
> > >> > Traceback (most recent call last):
> > >> >
> > >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 313, in
> 
> > >> >
> > >> > main()
> > >> >
> > >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 294, in
> main
> > >> >
> > >> > rev = prepare(c.root, c.version, c.key_id, c.key_password)
> > >> >
> > >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 98, in
> prepare
> > >> >
> > >> > checkDOAPfiles(version)
> > >> >
> > >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 143, in
> > >> > checkDOAPfiles
> > >> >
> > >> > distpage = load(url)
> > >> >
> > >> >   File "dev-tools/scripts/buildAndPushRelease.py", line 67, in 

[GitHub] lucene-solr issue #189: Jira/solr 6203

[jitka18]

Github user jitka18 commented on the issue:

https://github.com/apache/lucene-solr/pull/189
  
Hi, Christine.  I accepted your pull request and will update my branch from
the  master later today.   Will also take a look at the tests in DQCCST.

Thanks,
Judith

On Wed, Apr 19, 2017 at 1:19 PM, Christine Poerschke <
notificati...@github.com> wrote:

> Hi Judith - thanks for adding me to the collaborator list. I've added one
> more commit to the jitka18#1
>  request and would suggest
> something along the following lines as the next steps:
>
>- to review jitka18#1 
>and if it looks good merge it into your jira/solr-6203 branch and/or 
add
>comments on the pull request
>- to merge the latest master (at the time) into the jira/solr-6203
>working branch
>** this will give some merge conflicts that need to be resolved
>** this will somewhat reduce the scope and complexity of the changes
>for the working branch since SOLR-10394 part-2 renames will be picked 
up
>from the latest master
>- to see if new code duplication in 
DistributedQueryComponentCustomSortTest
>can be reduced further, this will not just reduce the amount of code 
but
>will (i think) also help with clarity i.e. what is being tested
>
> How does that sound? Any questions, please let me know. - Christine
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 

> .
>



---
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] [Comment Edited] (SOLR-10525) Stacked recovery requests can interfere with one another

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-10525 at 4/19/17 9:39 PM:
-

bq.  looks like the same issue of multiple requests stacking.

The reason for SOLR-8702 by the way is to examine no stacking at all. The issue 
that reduced stacking was titled more like "reduce stacking" not eliminate it. 
To eliminate it, we would want a patch and to examine if the change is worth 
any slow down in recovery calls we might have. Right now we can get hammered by 
recovery calls and they should all be very, very fast and result in few or no 
stack ups. Previously you stacked up every request.

In other words, if you eliminate stacking completely, is a recovery request 
going to cost more than a tryLock and atomic integer increment. Cause in the a 
concurrent env, that is super fast.


was (Author: markrmil...@gmail.com):
bq.  looks like the same issue of multiple requests stacking.

The reason for SOLR-8702 by the way is to examine no stacking at all. The issue 
that reduced stacking was titled more like "reduce stacking" not eliminate it. 
To eliminate it, we would want a patch and to examine if the change is worth 
any slow down in recovery calls we might have. Right now we can get hammered by 
recovery calls and they should all be very, very fast and result in few or no 
stack ups. Previously you stacked up every request.

> Stacked recovery requests can interfere with one another
> 
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
> Attachments: SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
>   boolean locked = recoveryLock.tryLock();
>   try {
> if (!locked) {
>   if (recoveryWaiting.get() > 0) { // line 1
> return;
>   }
>   recoveryWaiting.incrementAndGet(); // line 2
> } else {
>   recoveryWaiting.incrementAndGet();
>   cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no 
> recoveries to actually cancel (since we got the lock that means there are no 
> recoveries in progress). Instead it should be moved either to the either 
> branch of the if, or outside after the if since we know we will be running a 
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is 
> a recovery running, but no recoveries currently waiting, multiple requests 
> can check the count at line 1 before any of them will increment the count at 
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my 
> SOLR-9555 work in progress.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 10 object(s) that were not released!!! 
[MockDirectoryWrapper, MDCAwareThreadPoolExecutor, TransactionLog, 
TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, 
MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:360)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:720)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:947)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:854)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:958)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:893)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:88)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:370)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:355)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:306)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:647)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1154)  at 
org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949)  at 
org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225)
  at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.TransactionLog  at 

Re: Embeding distributed-solr in client-app without storing data

[Walter Underwood]

That is exactly what I thought you meant. Adds complexity with no benefit.

Now the merger needs to keep caches for global IDF. But those caches don’t get 
the benefit of other requests to the same cluster.

I’m not sure if query result caches cache the results of distributed queries, 
but if they do, then this approach looses that benefit too.

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


> On Apr 19, 2017, at 9:01 AM, Dorian Hoxha  wrote:
> 
> @Walter
> 
> Usually you have: client-app --> random-solr-node(mergerer) --> each other 
> node that has a shard
> While what I want: client-app (mergerer is in same jvm) --> each other node 
> that has a shard
> 
> Makes sense ?
> 
> On Wed, Apr 19, 2017 at 4:50 PM, Walter Underwood  > wrote:
> Does not make sense to me. It would do more queries from the client to the 
> cluster, not fewer. And those HTTP request would probably be slower than the 
> intra-cluster requests.
> 
> I expect the distributed portion of the query load is small compared to other 
> CPU usage.
> 
> It adds complexity for no gain in performance. Maybe a slight loss.
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org 
> http://observer.wunderwood.org/   (my blog)
> 
> 
>> On Apr 19, 2017, at 6:32 AM, Mikhail Khludnev > > wrote:
>> 
>> Hello, Dorian.
>> I'm not sure about 1. But you can create EmbeddedSolrServer and add 
>> "collection" parameter. It's what's done in 
>> org.apache.solr.response.transform.SubQueryAugmenter [subquery]
>> 
>> On Wed, Apr 19, 2017 at 3:53 PM, Dorian Hoxha > > wrote:
>> Hi friends,
>> 
>> Anybody has done this ? Reasons being: 1 less http-request when doing 
>> distributed search. But also not storing data itself (like a 
>> search-only-node). And the other nodes not caring about search-nodes.
>> 
>> Makes sense ?
>> 
>> Regards,
>> Dorian
>> 
>> 
>> 
>> -- 
>> Sincerely yours
>> Mikhail Khludnev
> 
> 

[jira] [Commented] (LUCENE-7789) replace & forbid "new FileInputStream" and "new FileOutputStream" with Files.newInputStream & Files.newOutputStream

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-7789:
--

 NOTE: I have not audited our own code to see how much of an impact the 
finalizers are likely to have in actual lucene/solr application instances, nor 
done any investigation into how feasible doing this sort of replacement would 
be given that in some cases I know we're using FileInputStream and 
FileOutputStream specific methods like "getChannel" ... not sure if there are 
related improvements in the "Files" class for dealing with those usecases w/o 
involving a finalizer.

> replace & forbid "new FileInputStream" and "new FileOutputStream" with 
> Files.newInputStream & Files.newOutputStream
> ---
>
> Key: LUCENE-7789
> URL: https://issues.apache.org/jira/browse/LUCENE-7789
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Hoss Man
>
> I haven't looked into the details of this much, but saw these links today and 
> thought it would be worth opening a jira for discussion...
> * 
> https://dzone.com/articles/fileinputstream-fileoutputstream-considered-harmful
> * https://issues.jenkins-ci.org/browse/JENKINS-42934
> * https://bugs.openjdk.java.net/browse/JDK-8080225
> The crux of the issue being that the "FileInputStream" and "FileOutputStream" 
> classes have finalizer methods with GC overhead that can be avoided using 
> Files.newInputStream and Files.newOutputStream in their place.
> This seems like it would make these methods good candidates for forbidding in 
> lucene/solr (if possible).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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.5.1 RC1

[David Smiley]

+1 works for me

On Wed, Apr 19, 2017 at 8:06 AM Joel Bernstein  wrote:

> Shall I cut an RC2 today?
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Tue, Apr 18, 2017 at 4:51 PM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> OK backported!
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Tue, Apr 18, 2017 at 4:41 PM, Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> Thanks for the suggestion David; I will backport LUCENE- shortly.
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> On Tue, Apr 18, 2017 at 2:55 PM, David Smiley 
>>> wrote:
>>>
 Hmm; there are a lot of Solr bugs fixed in 6.6 but not yet 6.5.1... I
 wonder why others aren't back-porting their fixed bugs?
 Lucene has one: LUCENE-  Mike should it be ported to 6.5.1?

 On Tue, Apr 18, 2017 at 1:28 PM Joel Bernstein 
 wrote:

> Sure
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Tue, Apr 18, 2017 at 1:20 PM, David Smiley <
> david.w.smi...@gmail.com> wrote:
>
>> I've been sitting on these bug fixes (see below) in case there will
>> be another RC and now it looks like there will be one.  Joel, shall I
>> commit them to the release branch?
>>
>>
>> On Mon, Apr 10, 2017 at 2:47 PM David Smiley <
>> david.w.smi...@gmail.com> wrote:
>>
>>> +1 SUCCESS! [0:48:18.176212]
>>>
>>> If there is a respin for any reason, I'd suggest including
>>> LUCENE-7769 (UH boost query) and SOLR-10439 ('large' and SchemaField)
>>>
>>> ~ David
>>>
>>> On Mon, Apr 10, 2017 at 2:07 PM Adrien Grand 
>>> wrote:
>>>
>>> +1 SUCCESS! [1:46:31.647123]
>>>
>>> Le lun. 10 avr. 2017 à 05:01, Joel Bernstein  a
>>> écrit :
>>>
>>> Please vote for release candidate 1 for Lucene/Solr 6.5.1The artifacts 
>>> can be downloaded from:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>>>
>>> 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.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>>>
>>> Here's my +1
>>>
>>> SUCCESS! [0:40:54.049621]
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>
> --
 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
 http://www.solrenterprisesearchserver.com

>>>
>>>
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Updated] (SOLR-10525) Stacked recovery requests can interfere with one another

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-10525:
-
Attachment: SOLR-10525.patch

Patch for 7.0 fixed, probably good for 6.x also (in which case whoever commits 
should move the changes entry)

> Stacked recovery requests can interfere with one another
> 
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
> Attachments: SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
>   boolean locked = recoveryLock.tryLock();
>   try {
> if (!locked) {
>   if (recoveryWaiting.get() > 0) { // line 1
> return;
>   }
>   recoveryWaiting.incrementAndGet(); // line 2
> } else {
>   recoveryWaiting.incrementAndGet();
>   cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no 
> recoveries to actually cancel (since we got the lock that means there are no 
> recoveries in progress). Instead it should be moved either to the either 
> branch of the if, or outside after the if since we know we will be running a 
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is 
> a recovery running, but no recoveries currently waiting, multiple requests 
> can check the count at line 1 before any of them will increment the count at 
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my 
> SOLR-9555 work in progress.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10525) Stacked recovery requests can interfere with one another

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-10525:
--

bq. The fact that multiple can still stack is as designed though
why? Looking at SOLR-8371 I see [~shalinmangar] noticed the same thing which 
went unanswered, and we also filed SOLR-8702 that looks like the same issue of 
multiple requests stacking.

> Stacked recovery requests can interfere with one another
> 
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
> Attachments: SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
>   boolean locked = recoveryLock.tryLock();
>   try {
> if (!locked) {
>   if (recoveryWaiting.get() > 0) { // line 1
> return;
>   }
>   recoveryWaiting.incrementAndGet(); // line 2
> } else {
>   recoveryWaiting.incrementAndGet();
>   cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no 
> recoveries to actually cancel (since we got the lock that means there are no 
> recoveries in progress). Instead it should be moved either to the either 
> branch of the if, or outside after the if since we know we will be running a 
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is 
> a recovery running, but no recoveries currently waiting, multiple requests 
> can check the count at line 1 before any of them will increment the count at 
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my 
> SOLR-9555 work in progress.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10525) Stacked recovery requests can interfere with one another

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10525:


Don't know if I answered Shalin's comment, but I've answered others about it. 
I'm sure that is part of SOLR-8702 being filed, but seems no one has worked on 
it. The current strategy was easy to get to from where were, and still very 
fast.

> Stacked recovery requests can interfere with one another
> 
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
> Attachments: SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
>   boolean locked = recoveryLock.tryLock();
>   try {
> if (!locked) {
>   if (recoveryWaiting.get() > 0) { // line 1
> return;
>   }
>   recoveryWaiting.incrementAndGet(); // line 2
> } else {
>   recoveryWaiting.incrementAndGet();
>   cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no 
> recoveries to actually cancel (since we got the lock that means there are no 
> recoveries in progress). Instead it should be moved either to the either 
> branch of the if, or outside after the if since we know we will be running a 
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is 
> a recovery running, but no recoveries currently waiting, multiple requests 
> can check the count at line 1 before any of them will increment the count at 
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my 
> SOLR-9555 work in progress.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10525) Stacked recovery requests can interfere with one another

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10525:


bq.  looks like the same issue of multiple requests stacking.

The reason for SOLR-8702 by the way is to examine no stacking at all. The issue 
that reduced stacking was titled more like "reduce stacking" not eliminate it. 
To eliminate it, we would want a patch and to examine if the change is worth 
any slow down in recovery calls we might have. Right now we can get hammered by 
recovery calls and they should all be very, very fast and result in few or no 
stack ups. Previously you stacked up every request.

> Stacked recovery requests can interfere with one another
> 
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
> Attachments: SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
>   boolean locked = recoveryLock.tryLock();
>   try {
> if (!locked) {
>   if (recoveryWaiting.get() > 0) { // line 1
> return;
>   }
>   recoveryWaiting.incrementAndGet(); // line 2
> } else {
>   recoveryWaiting.incrementAndGet();
>   cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no 
> recoveries to actually cancel (since we got the lock that means there are no 
> recoveries in progress). Instead it should be moved either to the either 
> branch of the if, or outside after the if since we know we will be running a 
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is 
> a recovery running, but no recoveries currently waiting, multiple requests 
> can check the count at line 1 before any of them will increment the count at 
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my 
> SOLR-9555 work in progress.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10525) Stacked recovery requests can interfere with one another

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10525:


Of course its complicated though. With the changes in SOLR-9555, we may finally 
be eliminating the main way we can get pounded with recovery requests (in a 
similar progress not perfection improvement, we have reduced how much pounding 
happens in the past).

> Stacked recovery requests can interfere with one another
> 
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
> Attachments: SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
>   boolean locked = recoveryLock.tryLock();
>   try {
> if (!locked) {
>   if (recoveryWaiting.get() > 0) { // line 1
> return;
>   }
>   recoveryWaiting.incrementAndGet(); // line 2
> } else {
>   recoveryWaiting.incrementAndGet();
>   cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no 
> recoveries to actually cancel (since we got the lock that means there are no 
> recoveries in progress). Instead it should be moved either to the either 
> branch of the if, or outside after the if since we know we will be running a 
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is 
> a recovery running, but no recoveries currently waiting, multiple requests 
> can check the count at line 1 before any of them will increment the count at 
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my 
> SOLR-9555 work in progress.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-5127) Allow multiple wildcards in hl.fl

[Sven-S. Porst (JIRA)]

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

Sven-S. Porst commented on SOLR-5127:
-

Cool, thanks for taking care of this [~cpoerschke]!

> Allow multiple wildcards in hl.fl
> -
>
> Key: SOLR-5127
> URL: https://issues.apache.org/jira/browse/SOLR-5127
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 3.6.1, 4.4
>Reporter: Sven-S. Porst
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: highlight-wildcards.patch, SOLR-5127.patch, 
> SOLR-5127.patch, SOLR-5127.patch
>
>
> When a wildcard is present in the hl.fl field, the field is not split up at 
> commas/spaces into components. As a consequence settings like 
> hl.fl=*_highlight,*_data do not work.
> Splitting the string first and evaluating wildcards on each component 
> afterwards would be more powerful and consistent with the documentation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10527) edismax with sow=false fails to create dismax-per-term queries when any field is boosted

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-10527:
-

 Summary: edismax with sow=false fails to create dismax-per-term 
queries when any field is boosted
 Key: SOLR-10527
 URL: https://issues.apache.org/jira/browse/SOLR-10527
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe


When {{sow=false}}, the edismax query parser creates dismax-per-field queries 
when field analysis is different enough that query structures differ per field 
(stopwords in one field only, e.g.).  (By contrast, dismax-per-*term* queries 
are produced when {{sow=true}} or when query structures are the same across all 
fields.)

However, the code to determine whether per-field query structures differed 
wasn't aware of boost queries.  As a result, when {{sow=false}} and boost are 
specified for at least one field (e.g. {{q=\{!edismax 
sow=false\}text=fieldA^2+fieldB^4}}), dismax-per-field queries are always 
produced, even when per-field query structures are equivalent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10527) edismax with sow=false fails to create dismax-per-term queries when any field is boosted

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10527:
--
Fix Version/s: master (7.0)
   6.6

> edismax with sow=false fails to create dismax-per-term queries when any field 
> is boosted
> 
>
> Key: SOLR-10527
> URL: https://issues.apache.org/jira/browse/SOLR-10527
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10527.patch
>
>
> When {{sow=false}}, the edismax query parser creates dismax-per-field queries 
> when field analysis is different enough that query structures differ per 
> field (stopwords in one field only, e.g.).  (By contrast, dismax-per-*term* 
> queries are produced when {{sow=true}} or when query structures are the same 
> across all fields.)
> However, the code to determine whether per-field query structures differed 
> wasn't aware of boost queries.  As a result, when {{sow=false}} and boost are 
> specified for at least one field (e.g. {{q=\{!edismax 
> sow=false\}text=fieldA^2+fieldB^4}}), dismax-per-field queries are always 
> produced, even when per-field query structures are equivalent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat resolved SOLR-10396.
-
Resolution: Fixed

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-10396:
-

Thanks [~shalinmangar] for review the patch.
Committed to branch 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=81e0f801f5145052cb25c533b134f4f5dcba972b

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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10528) Use docvalue for range faceting in JSON facet API

[Kensho Hirasawa (JIRA)]

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

Kensho Hirasawa commented on SOLR-10528:


Yonik, Thanks for the comment.

In the first patch, I added method parameter so that users can choose an 
implementation.
I'm going to remove the limitations first of all and then implement SMART 
method like terms facet.

> Use docvalue for range faceting in JSON facet API
> -
>
> Key: SOLR-10528
> URL: https://issues.apache.org/jira/browse/SOLR-10528
> Project: Solr
>  Issue Type: Improvement
>  Components: Facet Module
>Affects Versions: 6.5
>Reporter: Kensho Hirasawa
>Priority: Minor
> Attachments: SOLR-10528.patch
>
>
> Range faceting in JSON facet API has only one implementation. In the 
> implementation, all buckets are allocated and then range queries are executed 
> for all the buckets. Therefore, memory usage and computational cost of range 
> facet can be very high if range is wide and gap is narrow. 
> I think range faceting in JSON facet should have the implementation which 
> uses DocValues instead of inverted indices. By scanning DocValues, we can 
> execute range facets much more efficiently especially when the number of 
> buckets is large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Embeding distributed-solr in client-app without storing data

[Dorian Hoxha]

@Walter

Usually you have: client-app --> random-solr-node(mergerer) --> each other
node that has a shard
While what I want: client-app (mergerer is in same jvm) --> each other node
that has a shard

Makes sense ?

On Wed, Apr 19, 2017 at 4:50 PM, Walter Underwood 
wrote:

> Does not make sense to me. It would do more queries from the client to the
> cluster, not fewer. And those HTTP request would probably be slower than
> the intra-cluster requests.
>
> I expect the distributed portion of the query load is small compared to
> other CPU usage.
>
> It adds complexity for no gain in performance. Maybe a slight loss.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>
> On Apr 19, 2017, at 6:32 AM, Mikhail Khludnev  wrote:
>
> Hello, Dorian.
> I'm not sure about 1. But you can create EmbeddedSolrServer and add
> "collection" parameter. It's what's done in 
> org.apache.solr.response.transform.SubQueryAugmenter
> [subquery]
>
> On Wed, Apr 19, 2017 at 3:53 PM, Dorian Hoxha 
> wrote:
>
>> Hi friends,
>>
>> Anybody has done this ? Reasons being: 1 less http-request when doing
>> distributed search. But also not storing data itself (like a
>> search-only-node). And the other nodes not caring about search-nodes.
>>
>> Makes sense ?
>>
>> Regards,
>> Dorian
>>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
>
>

[jira] [Updated] (SOLR-10433) switch between v2 and v1 endpoints internally in SolrJ

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-10433:

Attachment: SOLR-10433.patch

Here are my strategy to accomplish this ticket. It uses code from SOLR-10431 
patch

> switch between v2 and v1 endpoints internally in SolrJ
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10528) Use docvalue for range faceting in JSON facet API

[Kensho Hirasawa (JIRA)]

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

Kensho Hirasawa commented on SOLR-10528:


I guess it is possible to avoid numeric boxing by stopping using generics but 
it leads to duplicated codes. Since the calculation of slot index can be 
modified a lot to support "include" parameter, I will remove numeric boxing 
after supporting it.

> Use docvalue for range faceting in JSON facet API
> -
>
> Key: SOLR-10528
> URL: https://issues.apache.org/jira/browse/SOLR-10528
> Project: Solr
>  Issue Type: Improvement
>  Components: Facet Module
>Affects Versions: 6.5
>Reporter: Kensho Hirasawa
>Priority: Minor
> Attachments: SOLR-10528.patch
>
>
> Range faceting in JSON facet API has only one implementation. In the 
> implementation, all buckets are allocated and then range queries are executed 
> for all the buckets. Therefore, memory usage and computational cost of range 
> facet can be very high if range is wide and gap is narrow. 
> I think range faceting in JSON facet should have the implementation which 
> uses DocValues instead of inverted indices. By scanning DocValues, we can 
> execute range facets much more efficiently especially when the number of 
> buckets is large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas null Last available 
state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"MissingSegmentRecoveryTest_shard1_replica1",   
"base_url":"http://127.0.0.1:56955/solr;,   
"node_name":"127.0.0.1:56955_solr",   "state":"active",   
"leader":"true"}, "core_node2":{   
"core":"MissingSegmentRecoveryTest_shard1_replica2",   
"base_url":"http://127.0.0.1:56954/solr;,   
"node_name":"127.0.0.1:56954_solr",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica1",
  "base_url":"http://127.0.0.1:56955/solr;,
  "node_name":"127.0.0.1:56955_solr",
  "state":"active",
  "leader":"true"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica2",
  "base_url":"http://127.0.0.1:56954/solr;,
  "node_name":"127.0.0.1:56954_solr",
  "state":"down",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([6C6CDF7F09088FC0:3C39477C502939DD]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19436/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseParallelGC

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:360)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:720)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:947)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:854)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:958)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:893)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:88)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:370)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:355)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:306)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.TransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.update.TransactionLog.(TransactionLog.java:190)  at 
org.apache.solr.update.UpdateLog.newTransactionLog(UpdateLog.java:438)  at 
org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:1250)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:524)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:509)  at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:348)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:267)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:217)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
  at 

[jira] [Updated] (SOLR-10527) edismax with sow=false fails to create dismax-per-term queries when any field is boosted

[Steve Rowe (JIRA)]

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

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

Patch with fix and tests.

Committing shortly.

> edismax with sow=false fails to create dismax-per-term queries when any field 
> is boosted
> 
>
> Key: SOLR-10527
> URL: https://issues.apache.org/jira/browse/SOLR-10527
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-10527.patch
>
>
> When {{sow=false}}, the edismax query parser creates dismax-per-field queries 
> when field analysis is different enough that query structures differ per 
> field (stopwords in one field only, e.g.).  (By contrast, dismax-per-*term* 
> queries are produced when {{sow=true}} or when query structures are the same 
> across all fields.)
> However, the code to determine whether per-field query structures differed 
> wasn't aware of boost queries.  As a result, when {{sow=false}} and boost are 
> specified for at least one field (e.g. {{q=\{!edismax 
> sow=false\}text=fieldA^2+fieldB^4}}), dismax-per-field queries are always 
> produced, even when per-field query structures are equivalent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10527) edismax with sow=false fails to create dismax-per-term queries when any field is boosted

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10527:


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

SOLR-10527: edismax with sow=false fails to create dismax-per-term queries when 
any field is boosted


> edismax with sow=false fails to create dismax-per-term queries when any field 
> is boosted
> 
>
> Key: SOLR-10527
> URL: https://issues.apache.org/jira/browse/SOLR-10527
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-10527.patch
>
>
> When {{sow=false}}, the edismax query parser creates dismax-per-field queries 
> when field analysis is different enough that query structures differ per 
> field (stopwords in one field only, e.g.).  (By contrast, dismax-per-*term* 
> queries are produced when {{sow=true}} or when query structures are the same 
> across all fields.)
> However, the code to determine whether per-field query structures differed 
> wasn't aware of boost queries.  As a result, when {{sow=false}} and boost are 
> specified for at least one field (e.g. {{q=\{!edismax 
> sow=false\}text=fieldA^2+fieldB^4}}), dismax-per-field queries are always 
> produced, even when per-field query structures are equivalent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Issue with 6.5.1 RC2

[Steve Rowe]

Joel,

I know you’re in-process with RC2, but if you have to restart for some reason, 
I’d like to include SOLR-10527.

--
Steve
www.lucidworks.com

> On Apr 19, 2017, at 6:57 PM, Joel Bernstein  wrote:
> 
> I also had to change the smoke tester because of the SSL issue. Which in 
> theory means everyone else will have to as well. I'm pushing out my changes 
> to branch_6_5, so people can just update their branch before running the 
> smoke tester.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> On Wed, Apr 19, 2017 at 5:02 PM, Joel Bernstein  wrote:
> Ok, I had to push out three changes to the branch but I seemed to have moved 
> passed this issue.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> On Wed, Apr 19, 2017 at 4:50 PM, Joel Bernstein  wrote:
> I'll push out the changes and then revert. Hopefully the changes will do the 
> trick after they've been pushed.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> On Wed, Apr 19, 2017 at 4:37 PM, Steve Rowe  wrote:
> Yeah, that is a sucky part of this: you want to make modifications on the 
> release branch, but you can’t test unless you commit (and push).
> 
> Another alternative: make modifications in another checkout, then invoke the 
> script with from an unmodified source tree.
> 
> e.g.:
> 
> cd ..
> cp -r lucene-solr lucene-solr-2 # assuming lucene-solr is your checkout dir
> # edit lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py
> cd lucene-solr
> python3 -u ../lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py …
> 
> (a shorter form of that is to make a copy the script alone and invoke the 
> modified version from your checkout)
> 
> --
> Steve
> www.lucidworks.com
> 
> > On Apr 19, 2017, at 4:32 PM, Joel Bernstein  wrote:
> >
> > Ha, that doesn't work either. Now I get this error:
> >
> > RuntimeError: There are unpushed commits - "git log origin/branch_6_5.." 
> > output is:
> >
> > So, I'm going to have to push this out.
> >
> > Let's first decide if this makes sense as the way forward.
> >
> >
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:28 PM, Joel Bernstein  wrote:
> > Steve, when I change the script to turn off verification I get the 
> > following error:
> > RuntimeError: git clone is dirty:
> >
> > So as part of the work around I think I'm going to have to commit locally 
> > and then revert locally. Does that make sense to you as the way forward?
> >
> >
> >
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:24 PM, Alexandre Rafalovitch  
> > wrote:
> > Could it be anything to do with the fact that the signer is Semantic
> > and they are being actively distrusted by - at least - Google:
> > http://www.securityweek.com/google-stops-trusting-symantec-issued-certificates
> >
> > Regards,
> >Alex.
> > 
> > http://www.solr-start.com/ - Resources for Solr users, new and experienced
> >
> >
> > On 19 April 2017 at 16:22, Joel Bernstein  wrote:
> > > Ok, I'll turn off the cert verification. I wasn't sure if cert 
> > > verification
> > > was something that was integral to the process.
> > >
> > > Joel Bernstein
> > > http://joelsolr.blogspot.com/
> > >
> > > On Wed, Apr 19, 2017 at 4:18 PM, Steve Rowe  wrote:
> > >>
> > >> Hi Joel,
> > >>
> > >> Not sure why this is suddenly an issue - I guess “SNI”
> > >>  has been enabled 
> > >> on
> > >> archive.apache.org?
> > >>
> > >> Some useful info here (about a “requests” lib, AFAICT an alternative to
> > >> urllib):
> > >> 
> > >>
> > >> Short term, you could turn off certificate verification.  The bottom
> > >> answer here uses the same lib as the script (urllib instead of urllib2,
> > >> which is assumed in the other answers on the page), to turn off 
> > >> certificate
> > >> verification:
> > >>
> > >>
> > >> 
> > >>
> > >> --
> > >> Steve
> > >> www.lucidworks.com
> > >>
> > >> > On Apr 19, 2017, at 3:43 PM, Joel Bernstein  wrote:
> > >> >
> > >> > It appears that it's failing on verifying the SSL cert for
> > >> > https://archive.apache.org/dist/lucene/java/.
> > >> >
> > >> >
> > >> >
> > >> > Joel Bernstein
> > >> > http://joelsolr.blogspot.com/
> > >> >
> > >> > On Wed, Apr 19, 2017 at 3:36 PM, Joel Bernstein 
> > >> > wrote:
> > >> > I started working on 6.5.1 RC2. I ran the following:
> > >> > python3 -u dev-tools/scripts/buildAndPushRelease.py --push-local
> > >> > /tmp/releases/6.5.1 --rc-num 2 --sign EE64CB1E
> > >> >
> > >> > I believe this is same basic command I used for RC1. But this time I 
> 

Re: Issue with 6.5.1 RC2

[Joel Bernstein]

I'm OK with restarting RC2. Let me know when you finish the back port.

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

On Wed, Apr 19, 2017 at 7:11 PM, Steve Rowe  wrote:

> Joel,
>
> I know you’re in-process with RC2, but if you have to restart for some
> reason, I’d like to include SOLR-10527.
>
> --
> Steve
> www.lucidworks.com
>
> > On Apr 19, 2017, at 6:57 PM, Joel Bernstein  wrote:
> >
> > I also had to change the smoke tester because of the SSL issue. Which in
> theory means everyone else will have to as well. I'm pushing out my changes
> to branch_6_5, so people can just update their branch before running the
> smoke tester.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 5:02 PM, Joel Bernstein 
> wrote:
> > Ok, I had to push out three changes to the branch but I seemed to have
> moved passed this issue.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:50 PM, Joel Bernstein 
> wrote:
> > I'll push out the changes and then revert. Hopefully the changes will do
> the trick after they've been pushed.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:37 PM, Steve Rowe  wrote:
> > Yeah, that is a sucky part of this: you want to make modifications on
> the release branch, but you can’t test unless you commit (and push).
> >
> > Another alternative: make modifications in another checkout, then invoke
> the script with from an unmodified source tree.
> >
> > e.g.:
> >
> > cd ..
> > cp -r lucene-solr lucene-solr-2 # assuming lucene-solr is your checkout
> dir
> > # edit lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py
> > cd lucene-solr
> > python3 -u ../lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py …
> >
> > (a shorter form of that is to make a copy the script alone and invoke
> the modified version from your checkout)
> >
> > --
> > Steve
> > www.lucidworks.com
> >
> > > On Apr 19, 2017, at 4:32 PM, Joel Bernstein 
> wrote:
> > >
> > > Ha, that doesn't work either. Now I get this error:
> > >
> > > RuntimeError: There are unpushed commits - "git log
> origin/branch_6_5.." output is:
> > >
> > > So, I'm going to have to push this out.
> > >
> > > Let's first decide if this makes sense as the way forward.
> > >
> > >
> > >
> > >
> > >
> > > Joel Bernstein
> > > http://joelsolr.blogspot.com/
> > >
> > > On Wed, Apr 19, 2017 at 4:28 PM, Joel Bernstein 
> wrote:
> > > Steve, when I change the script to turn off verification I get the
> following error:
> > > RuntimeError: git clone is dirty:
> > >
> > > So as part of the work around I think I'm going to have to commit
> locally and then revert locally. Does that make sense to you as the way
> forward?
> > >
> > >
> > >
> > >
> > >
> > >
> > > Joel Bernstein
> > > http://joelsolr.blogspot.com/
> > >
> > > On Wed, Apr 19, 2017 at 4:24 PM, Alexandre Rafalovitch <
> arafa...@gmail.com> wrote:
> > > Could it be anything to do with the fact that the signer is Semantic
> > > and they are being actively distrusted by - at least - Google:
> > > http://www.securityweek.com/google-stops-trusting-
> symantec-issued-certificates
> > >
> > > Regards,
> > >Alex.
> > > 
> > > http://www.solr-start.com/ - Resources for Solr users, new and
> experienced
> > >
> > >
> > > On 19 April 2017 at 16:22, Joel Bernstein  wrote:
> > > > Ok, I'll turn off the cert verification. I wasn't sure if cert
> verification
> > > > was something that was integral to the process.
> > > >
> > > > Joel Bernstein
> > > > http://joelsolr.blogspot.com/
> > > >
> > > > On Wed, Apr 19, 2017 at 4:18 PM, Steve Rowe 
> wrote:
> > > >>
> > > >> Hi Joel,
> > > >>
> > > >> Not sure why this is suddenly an issue - I guess “SNI”
> > > >>  has been
> enabled on
> > > >> archive.apache.org?
> > > >>
> > > >> Some useful info here (about a “requests” lib, AFAICT an
> alternative to
> > > >> urllib):
> > > >>  what-are-hostname-doesn-t-match-errors>
> > > >>
> > > >> Short term, you could turn off certificate verification.  The bottom
> > > >> answer here uses the same lib as the script (urllib instead of
> urllib2,
> > > >> which is assumed in the other answers on the page), to turn off
> certificate
> > > >> verification:
> > > >>
> > > >>
> > > >>  ignore-certicate-validation-urllib2>
> > > >>
> > > >> --
> > > >> Steve
> > > >> www.lucidworks.com
> > > >>
> > > >> > On Apr 19, 2017, at 3:43 PM, Joel Bernstein 
> wrote:
> > > >> >
> > > >> > It appears that it's failing on verifying the SSL cert for
> > > >> > https://archive.apache.org/dist/lucene/java/.
> > > >> >
> > > >> >
> > > >> >
> > > >> > Joel Bernstein

Re: Issue with 6.5.1 RC2

[Steve Rowe]

Woohoo!  Thanks Joel.  Running all tests on branch_6_5 now.

--
Steve
www.lucidworks.com

> On Apr 19, 2017, at 7:20 PM, Joel Bernstein  wrote:
> 
> I'm OK with restarting RC2. Let me know when you finish the back port.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> On Wed, Apr 19, 2017 at 7:11 PM, Steve Rowe  wrote:
> Joel,
> 
> I know you’re in-process with RC2, but if you have to restart for some 
> reason, I’d like to include SOLR-10527.
> 
> --
> Steve
> www.lucidworks.com
> 
> > On Apr 19, 2017, at 6:57 PM, Joel Bernstein  wrote:
> >
> > I also had to change the smoke tester because of the SSL issue. Which in 
> > theory means everyone else will have to as well. I'm pushing out my changes 
> > to branch_6_5, so people can just update their branch before running the 
> > smoke tester.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 5:02 PM, Joel Bernstein  wrote:
> > Ok, I had to push out three changes to the branch but I seemed to have 
> > moved passed this issue.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:50 PM, Joel Bernstein  wrote:
> > I'll push out the changes and then revert. Hopefully the changes will do 
> > the trick after they've been pushed.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Wed, Apr 19, 2017 at 4:37 PM, Steve Rowe  wrote:
> > Yeah, that is a sucky part of this: you want to make modifications on the 
> > release branch, but you can’t test unless you commit (and push).
> >
> > Another alternative: make modifications in another checkout, then invoke 
> > the script with from an unmodified source tree.
> >
> > e.g.:
> >
> > cd ..
> > cp -r lucene-solr lucene-solr-2 # assuming lucene-solr is your checkout dir
> > # edit lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py
> > cd lucene-solr
> > python3 -u ../lucene-solr-2/dev-tools/scripts/buildAndPushRelease.py …
> >
> > (a shorter form of that is to make a copy the script alone and invoke the 
> > modified version from your checkout)
> >
> > --
> > Steve
> > www.lucidworks.com
> >
> > > On Apr 19, 2017, at 4:32 PM, Joel Bernstein  wrote:
> > >
> > > Ha, that doesn't work either. Now I get this error:
> > >
> > > RuntimeError: There are unpushed commits - "git log origin/branch_6_5.." 
> > > output is:
> > >
> > > So, I'm going to have to push this out.
> > >
> > > Let's first decide if this makes sense as the way forward.
> > >
> > >
> > >
> > >
> > >
> > > Joel Bernstein
> > > http://joelsolr.blogspot.com/
> > >
> > > On Wed, Apr 19, 2017 at 4:28 PM, Joel Bernstein  
> > > wrote:
> > > Steve, when I change the script to turn off verification I get the 
> > > following error:
> > > RuntimeError: git clone is dirty:
> > >
> > > So as part of the work around I think I'm going to have to commit locally 
> > > and then revert locally. Does that make sense to you as the way forward?
> > >
> > >
> > >
> > >
> > >
> > >
> > > Joel Bernstein
> > > http://joelsolr.blogspot.com/
> > >
> > > On Wed, Apr 19, 2017 at 4:24 PM, Alexandre Rafalovitch 
> > >  wrote:
> > > Could it be anything to do with the fact that the signer is Semantic
> > > and they are being actively distrusted by - at least - Google:
> > > http://www.securityweek.com/google-stops-trusting-symantec-issued-certificates
> > >
> > > Regards,
> > >Alex.
> > > 
> > > http://www.solr-start.com/ - Resources for Solr users, new and experienced
> > >
> > >
> > > On 19 April 2017 at 16:22, Joel Bernstein  wrote:
> > > > Ok, I'll turn off the cert verification. I wasn't sure if cert 
> > > > verification
> > > > was something that was integral to the process.
> > > >
> > > > Joel Bernstein
> > > > http://joelsolr.blogspot.com/
> > > >
> > > > On Wed, Apr 19, 2017 at 4:18 PM, Steve Rowe  wrote:
> > > >>
> > > >> Hi Joel,
> > > >>
> > > >> Not sure why this is suddenly an issue - I guess “SNI”
> > > >>  has been 
> > > >> enabled on
> > > >> archive.apache.org?
> > > >>
> > > >> Some useful info here (about a “requests” lib, AFAICT an alternative to
> > > >> urllib):
> > > >> 
> > > >>
> > > >> Short term, you could turn off certificate verification.  The bottom
> > > >> answer here uses the same lib as the script (urllib instead of urllib2,
> > > >> which is assumed in the other answers on the page), to turn off 
> > > >> certificate
> > > >> verification:
> > > >>
> > > >>
> > > >> 
> > > >>
> > > >> --
> > > >> Steve
> > > >> www.lucidworks.com
> > > >>
> > > >> > On Apr 19, 2017, at 3:43 PM, Joel Bernstein 

[jira] [Commented] (SOLR-10527) edismax with sow=false fails to create dismax-per-term queries when any field is boosted

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10527:


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

SOLR-10527: move CHANGES entry to 6.5.1 section


> edismax with sow=false fails to create dismax-per-term queries when any field 
> is boosted
> 
>
> Key: SOLR-10527
> URL: https://issues.apache.org/jira/browse/SOLR-10527
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10527.patch
>
>
> When {{sow=false}}, the edismax query parser creates dismax-per-field queries 
> when field analysis is different enough that query structures differ per 
> field (stopwords in one field only, e.g.).  (By contrast, dismax-per-*term* 
> queries are produced when {{sow=true}} or when query structures are the same 
> across all fields.)
> However, the code to determine whether per-field query structures differed 
> wasn't aware of boost queries.  As a result, when {{sow=false}} and boost are 
> specified for at least one field (e.g. {{q=\{!edismax 
> sow=false\}text=fieldA^2+fieldB^4}}), dismax-per-field queries are always 
> produced, even when per-field query structures are equivalent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10527) edismax with sow=false fails to create dismax-per-term queries when any field is boosted

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10527:


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

SOLR-10527: move CHANGES entry to 6.5.1 section


> edismax with sow=false fails to create dismax-per-term queries when any field 
> is boosted
> 
>
> Key: SOLR-10527
> URL: https://issues.apache.org/jira/browse/SOLR-10527
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10527.patch
>
>
> When {{sow=false}}, the edismax query parser creates dismax-per-field queries 
> when field analysis is different enough that query structures differ per 
> field (stopwords in one field only, e.g.).  (By contrast, dismax-per-*term* 
> queries are produced when {{sow=true}} or when query structures are the same 
> across all fields.)
> However, the code to determine whether per-field query structures differed 
> wasn't aware of boost queries.  As a result, when {{sow=false}} and boost are 
> specified for at least one field (e.g. {{q=\{!edismax 
> sow=false\}text=fieldA^2+fieldB^4}}), dismax-per-field queries are always 
> produced, even when per-field query structures are equivalent.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10528) Use docvalue for range faceting in JSON facet API

[Kensho Hirasawa (JIRA)]

Kensho Hirasawa created SOLR-10528:
--

 Summary: Use docvalue for range faceting in JSON facet API
 Key: SOLR-10528
 URL: https://issues.apache.org/jira/browse/SOLR-10528
 Project: Solr
  Issue Type: Improvement
  Components: Facet Module
Affects Versions: 6.5
Reporter: Kensho Hirasawa
Priority: Minor


Range faceting in JSON facet API has only one implementation. In the 
implementation, all buckets are allocated and then range queries are executed 
for all the buckets. Therefore, memory usage and computational cost of range 
facet can be very high if range is wide and gap is narrow. 

I think range faceting in JSON facet should have the implementation which uses 
DocValues instead of inverted indices. By scanning DocValues, we can execute 
range facets much more efficiently especially when the number of buckets is 
large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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