Re: Why no composite primary-key in lucene ?

[Dorian Hoxha]

@Erick,

I kinda have to learn somehow. And I like to do performance optimizations.
So learning + fun + performance .. yeah.
Other projects that I want to do are harder (our email-exchange, my other
threads on the list) so I have to start on something simpler.

Example:
I have a project where `id` is 3 long fields which are already
indexed+stored (each doc is 10 - 20 long fields (so 1/4 more data for the
id?)), think event-store. The data needs to be in-memory + many
queries/second + records are always increasing etc.





On Sat, Apr 29, 2017 at 9:44 PM, Erick Erickson 
wrote:

> What you haven't really explained is why you care. The only hint I see
> is that you don't want to store the redundant data of your composite
> key as both individual fields and a concatenated .
>
> This feels like a whole lot of effort for no particularly good reason.
> Unless you have a bazillion _very_ short docs, concatenating the parts
> together in your  field is unlikely to be of measurable
> consequence. If you have _measurements_ showing that's not true, it's
> another story.
>
> Assuming I'm on the right path here, I'd guess there are much more
> valuable things you could spend engineering time on than the rabbit
> hole of trying to work around Solr's way of dealing with 
> ;)..
>
> Best,
> Erick
>
> On Sat, Apr 29, 2017 at 11:38 AM, Dorian Hoxha 
> wrote:
> > @Yonik Thanks, makes sense.
> >
> > @Walter
> >
> > After reading the cwiki page on update request processor looks like you
> > can't modify the GET/DELETE handlers, right ?
> > Because I want to NOT index/store the 'id' field, so clients/solr-cloud
> > (which needs /get) continue to work normally but internally 'id' appears
> > only in translog.
> > And I need to do something similar for GET/DELETE.
> >
> > How to do that ?
> >
> > Regards,
> > Dorian
> >
> > On Sat, Apr 29, 2017 at 8:04 PM, Walter Underwood  >
> > wrote:
> >>
> >> If you do want a composite key in Solr, you could use an update request
> >> processor script to make it out of the multiple fields.
> >>
> >> wunder
> >> Walter Underwood
> >> wun...@wunderwood.org
> >> http://observer.wunderwood.org/  (my blog)
> >>
> >>
> >> On Apr 29, 2017, at 11:02 AM, Yonik Seeley  wrote:
> >>
> >> On Sat, Apr 29, 2017 at 1:45 PM, Dorian Hoxha 
> >> wrote:
> >>
> >> @Yonik
> >>
> >> Thanks makes sense. So this means that the 'id' need to be indexed(is
> >> always?), (so you can get/update/delete docs not in translog), right ?
> >>
> >>
> >> In Solr, yes.  In Lucene, only if you want lookup-by-id to be fast, or
> >> if you want to use updateDocument with an indexed term for overwriting
> >> documents.
> >>
> >> -Yonik
> >>
> >>
> >> On Sat, Apr 29, 2017 at 7:24 PM, Yonik Seeley 
> wrote:
> >>
> >>
> >> Solr doesn't use Lucene for RT GET, it uses it's transaction log.
> >> Only when the document is not found in the transaction log will it go
> >> and consult the lucene index (which can only search as of the last
> >> commit).
> >>
> >> -Yonik
> >>
> >> On Sat, Apr 29, 2017 at 12:57 PM, Dorian Hoxha 
> >> wrote:
> >>
> >> I know all that. My point is, lucene is NRT, while GET is RT (in both
> >> ES/SOLR). How does lucene return the right document (Term Query) before
> >> doing a commit on GET ?
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (SOLR-9867) The Solr examples can not always be started after being stopped due to race with loading core.

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-9867:
-
Attachment: SOLR-9867.patch

Fixed some indentation issues, but otherwise identical.

FWIW, I'm curious to see if this is related to SOLR-10562 and the recent 
SolrCloudExampleTest failures so I'm beasting this latter tonight. Sometime 
soon I'll uncrank the debugging I had in SOLR-10562.

All this has to do with reloading, so I figured I'd at least see.

> The Solr examples can not always be started after being stopped due to race 
> with loading core.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Priority: Critical
> Fix For: 6.6, master (7.0)
>
> Attachments: SDF init and doFilter in parallel.png, SOLR-9867.patch, 
> SOLR-9867.patch, SOLR-9867.patch, SOLR-9867.patch, SOLR-9867-test.patch
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an 
> error when it tries to create the SolrCore (again, it already exists) and so 
> it deletes the cores instance dir which leads to tlog and index lock errors 
> in Solr.
> The reason it seems to be trying to create the core when it already exists is 
> that the run example tool uses a core status call to check existence and 
> because the core is loading, we don't consider it as existing. I added a 
> check to look for core.properties.
> That seemed to let me start up, but my first requests failed because the core 
> was still loading. It appears CoreContainer#getCore  is supposed to be 
> blocking so you don't have this problem, but there must be an issue, because 
> it is not blocking.



--
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-10519) SolrCLI.atPath cannot handle children that begin with a slash.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10519:
---

Unless anyone objects, I'm going to commit this probably tomorrow.

> SolrCLI.atPath cannot handle children that begin with a slash.
> --
>
> Key: SOLR-10519
> URL: https://issues.apache.org/jira/browse/SOLR-10519
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5, master (7.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-10519.patch, SOLR-10519.patch
>
>
> When getting an element of a configuration from JSON where the _name_ of one 
> of the elements in the tree begins with a slash (e.g. /query), SolrCLI.atPath 
> fails because it splits on the slash.
> We either need a way to escape it or add an alternate delimiter. Here's one 
> way that works, what do people think?



--
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-7041) Remove defaultSearchField and solrQueryParser from schema

[Pradeep (JIRA)]

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

Pradeep commented on SOLR-7041:
---

Bad. removing defaultOperator and defaultSearchField is bad idea. 

> Remove defaultSearchField and solrQueryParser from schema
> -
>
> Key: SOLR-7041
> URL: https://issues.apache.org/jira/browse/SOLR-7041
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0
>
> Attachments: SOLR-7041-defaultOperator.patch, SOLR-7041.patch
>
>
> The two tags {{}} and {{solrQueryParser}} were deprecated 
> in Solr3.6 (SOLR-2724). Time to nuke them from code and {{schema.xml}} in 5.0?



--
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-1485) Payload scoring support

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-1485:


I've now committed/pushed everything to the branch needed for the payload() 
function, including the dynamic field types for delimited payloading of terms.  
 I think we could call this JIRA satisfied with what's committed so far, 
however I've got these pieces in addition locally: PayloadCheckQParserPlugin, 
PayloadScoreQParserPlugin.java, PayloadScoringSimilarityWrapper.java, and an 
improvement to xmlparser's  - may include these along with 
this issue, not sure yet.

> 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: 6.6, master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, 
> SOLR-1485.patch, 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] [Commented] (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=15990095#comment-15990095
 ] 

Erik Hatcher commented on SOLR-1485:


I've started committing to branch jira/SOLR-1485: 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/SOLR-1485
 where I've just committed the payload() function (and tests and helper 
utilities)

> 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: 6.6, master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, 
> SOLR-1485.patch, 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] [Updated] (SOLR-10586) Ban defaultOperator in schema for luceneMatchVersion =>6.6.0

[JIRA]

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

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

Patch for branch_6x. Will commit shortly, and then followup to remove 
{{defaultOperator}} completely in master

> Ban defaultOperator in schema for luceneMatchVersion =>6.6.0
> 
>
> Key: SOLR-10586
> URL: https://issues.apache.org/jira/browse/SOLR-10586
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.6
>
> Attachments: SOLR-10586.patch
>
>
> Sub task of SOLR-7041.
> For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
> defaultOperator is used in schema.
> For luceneMatchVersion < 6.0.0 we'll behave like before (warn only). This is 
> to deliver on our back-compat promise between minor versions.



--
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-10586) Ban defaultOperator in schema for luceneMatchVersion =>6.6.0

[JIRA]

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

Jan Høydahl updated SOLR-10586:
---
Description: 
Sub task of SOLR-7041.

For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
defaultOperator is used in schema.

For luceneMatchVersion < 6.6.0 we'll behave like before (warn only). This is to 
deliver on our back-compat promise between minor versions.

  was:
Sub task of SOLR-7041.

For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
defaultOperator is used in schema.

For luceneMatchVersion < 6.0.0 we'll behave like before (warn only). This is to 
deliver on our back-compat promise between minor versions.


> Ban defaultOperator in schema for luceneMatchVersion =>6.6.0
> 
>
> Key: SOLR-10586
> URL: https://issues.apache.org/jira/browse/SOLR-10586
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.6
>
> Attachments: SOLR-10586.patch
>
>
> Sub task of SOLR-7041.
> For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
> defaultOperator is used in schema.
> For luceneMatchVersion < 6.6.0 we'll behave like before (warn only). This is 
> to deliver on our back-compat promise between minor versions.



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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6534/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseG1GC

2 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, 
MockDirectoryWrapper, TransactionLog] 
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:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  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.execute(ExecuteProduceConsume.java:100)
  at org.eclipse.jetty.io.ManagedSelector.run(ManagedSelector.java:147)  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.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:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  at 

[jira] [Assigned] (SOLR-10586) Ban defaultOperator in schema for luceneMatchVersion =>6.6.0

[JIRA]

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

Jan Høydahl reassigned SOLR-10586:
--

Assignee: Jan Høydahl

> Ban defaultOperator in schema for luceneMatchVersion =>6.6.0
> 
>
> Key: SOLR-10586
> URL: https://issues.apache.org/jira/browse/SOLR-10586
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.6
>
>
> Sub task of SOLR-7041.
> For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
> defaultOperator is used in schema.
> For luceneMatchVersion < 6.0.0 we'll behave like before (warn only). This is 
> to deliver on our back-compat promise between minor versions.



--
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: Release 6.6

[Erik Hatcher]

Martin -

Interesting test but I couldn’t copy/paste it in to try it out as it uses some 
logging and APIs that aren’t already in the project and classpath of these 
lucene tests within that queries module (within IntelliJ, mind you).

I was able to resolve the misunderstanding (and .equals/.hashCode bugs) so 
everything is working as expected with SpanPayloadCheckQuery for me now.   Do 
your tests point out an issue?   Or confirming that it is working properly at a 
lower level?

Erik


> On Apr 29, 2017, at 9:08 AM, Martin Gainty  wrote:
> 
> Martin Gainty has shared a OneDrive file with you. To view it, click the link 
> below.
>   
> TestPayloadCheckQuery.java
>   
> 
> TestPayloadCheckQuery.java 
> attached
> 
> I coded this last nite so it is "quick and dirty"
> 
> in any case let me know if  testSpanPayloadCheck() method modification 
> properly addresses your situation
> 
> Thanks!
> Martin 
> __ 
> 
> 
> 
> From: Erik Hatcher 
> Sent: Saturday, April 29, 2017 8:58 AM
> To: dev@lucene.apache.org
> Subject: Re: Release 6.6
>  
> Martin - there is a test class specifically for this query.   See the recent 
> commits I've made to test it further fixing .equals/.hashCode and rewrite. 
> 
> Can you send your full test code?
> 
>Erik
> 
> On Apr 29, 2017, at 07:32, Martin Gainty  > wrote:
> 
>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was about 
>> to reply just run that TestCase
>> (until i discovered there wasnt any!)
>> 
>> i'll start the bidding at 1 dinar for TestCase 
>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>   @org.junit.Test
>>   public void testSpanPayloadCheck() throws Exception
>> 
>> //now lets test the collectLeaf for query
>> //of course calling Base Class SpanPayloadCheckQuery to construct query
>> 
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before 
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>  (int)position,(org.apache.lucene.index.Term)term1) where 
>> postings="+postings);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before 
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>  (int)position,(org.apache.lucene.index.Term)term1) where 
>> position="+position);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before 
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>  (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>> 
>> try
>> { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum 
>> postings, int position,  //org.apache.lucene.index.Term term) 
>> throws java.io.IOException {
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>  (int)position,(org.apache.lucene.index.Term)term1);
>> }
>> catch(java.io.IOException ioe) { 
>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>  (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws 
>> IOException ="+ioe.getMessage()); }
>> 
>> unless of course anyone has a better idea to test collectLeaf ?
>> Martin 
>> __ 
>> 
>> 
>> 
>> From: Erik Hatcher >
>> Sent: Tuesday, April 25, 2017 7:57 PM
>> To: dev@lucene.apache.org 
>> Subject: Re: Release 6.6
>>  
>> Probably no bribe needed, but an updated patch would be a good start (or 
>> will the 2.5 year old patch still apply and be acceptable as-is?)
>> 
>> Erik
>> 
>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood >> > wrote:
>>> 
>>> Who do I have to bribe to get SOLR-629 included?
>>> 
>>> https://issues.apache.org/jira/browse/SOLR-629 
>>> 
>>> 
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org 
>>> http://observer.wunderwood.org/   (my blog)
>>> 
>>> 
 On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya 
 > wrote:
 
 Hi,
 We have lots of changes, optimizations, bug fixes for 6.6. I'd like to 
 propose a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0 
 release).
 
 I can volunteer to release this, and I can cut the release branch around 
 4th May, in order to let some time for devs to finish current issues.
 

[jira] [Updated] (SOLR-7041) Remove defaultSearchField and solrQueryParser from schema

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-7041:
---
Summary: Remove defaultSearchField and solrQueryParser from schema  (was: 
Nuke defaultSearchField and solrQueryParser from schema)

> Remove defaultSearchField and solrQueryParser from schema
> -
>
> Key: SOLR-7041
> URL: https://issues.apache.org/jira/browse/SOLR-7041
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0
>
> Attachments: SOLR-7041-defaultOperator.patch, SOLR-7041.patch
>
>
> The two tags {{}} and {{solrQueryParser}} were deprecated 
> in Solr3.6 (SOLR-2724). Time to nuke them from code and {{schema.xml}} in 5.0?



--
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-10587) Ban defaultSearchField in schema for luceneMatchVersion =>6.6.0

[JIRA]

Jan Høydahl created SOLR-10587:
--

 Summary: Ban defaultSearchField in schema for luceneMatchVersion 
=>6.6.0
 Key: SOLR-10587
 URL: https://issues.apache.org/jira/browse/SOLR-10587
 Project: Solr
  Issue Type: Sub-task
  Components: Schema and Analysis
Reporter: Jan Høydahl
 Fix For: 6.6


Sub task of SOLR-7041.

For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
defaultSearchField is used in schema.

For luceneMatchVersion < 6.0.0 we'll behave like before (warn only). This is to 
deliver on our back-compat promise between minor versions.



--
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-7041) Nuke defaultSearchField and solrQueryParser from schema

[JIRA]

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

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

Further work will happen in the sub tasks, to split the elephant a bit

> Nuke defaultSearchField and solrQueryParser from schema
> ---
>
> Key: SOLR-7041
> URL: https://issues.apache.org/jira/browse/SOLR-7041
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0
>
> Attachments: SOLR-7041-defaultOperator.patch, SOLR-7041.patch
>
>
> The two tags {{}} and {{solrQueryParser}} were deprecated 
> in Solr3.6 (SOLR-2724). Time to nuke them from code and {{schema.xml}} in 5.0?



--
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-10586) Ban defaultOperator in schema for luceneMatchVersion =>6.6.0

[JIRA]

Jan Høydahl created SOLR-10586:
--

 Summary: Ban defaultOperator in schema for luceneMatchVersion 
=>6.6.0
 Key: SOLR-10586
 URL: https://issues.apache.org/jira/browse/SOLR-10586
 Project: Solr
  Issue Type: Sub-task
Reporter: Jan Høydahl
 Fix For: 6.6


Sub task of SOLR-7041.

For new configs with luceneMatchVersion >=6.6.0 we'll throw an exception if  
defaultOperator is used in schema.

For luceneMatchVersion < 6.0.0 we'll behave like before (warn only). This is to 
deliver on our back-compat promise between minor versions.



--
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-10585) Remove defaultSearchField completely in 7.0

[JIRA]

Jan Høydahl created SOLR-10585:
--

 Summary: Remove defaultSearchField completely in 7.0
 Key: SOLR-10585
 URL: https://issues.apache.org/jira/browse/SOLR-10585
 Project: Solr
  Issue Type: Sub-task
  Components: Schema and Analysis
Reporter: Jan Høydahl
 Fix For: master (7.0)


Sub task of SOLR-7041.

This will remove code related to defaultSearchField in schema and will throw a 
hard exception if a schema using this config is attempted loaded.



--
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-10584) Remove defaultOperator completely in 7.0

[JIRA]

Jan Høydahl created SOLR-10584:
--

 Summary: Remove defaultOperator completely in 7.0
 Key: SOLR-10584
 URL: https://issues.apache.org/jira/browse/SOLR-10584
 Project: Solr
  Issue Type: Sub-task
Reporter: Jan Høydahl


Sub task of SOLR-7041.

This will remove code related to defaultOperator in schema and will throw a 
hard exception if a schema using this config is attempted loaded.



--
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-7041) Nuke defaultSearchField and solrQueryParser from schema

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7041: Remove a lot of defaultOperator and defaultSearchField from test 
configs (still more work to do)

(cherry picked from commit 8ecdd67)


> Nuke defaultSearchField and solrQueryParser from schema
> ---
>
> Key: SOLR-7041
> URL: https://issues.apache.org/jira/browse/SOLR-7041
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0
>
> Attachments: SOLR-7041-defaultOperator.patch, SOLR-7041.patch
>
>
> The two tags {{}} and {{solrQueryParser}} were deprecated 
> in Solr3.6 (SOLR-2724). Time to nuke them from code and {{schema.xml}} in 5.0?



--
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-9867) The Solr examples can not always be started after being stopped due to race with loading core.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9867:
---
Attachment: SOLR-9867.patch

[^SOLR-9867.patch] is on 6x. It enables {{testTechproductsExample}} and makes 
{{beast}} happy about it. Therefore, there should be some work to fix tests, 
which are currently failing on ci.  
 - the patch makes core status aware of loading cores and latches 
SolrDispatchFilter.doFilter on init. Otherwise, status request might be handled 
before core starts load in background. I always though that a servlet container 
provides init/doFilter latching, so naive.
 - perhaps, instead of latch we can assign {{cores}} strictly at the end of 
{{init}}. What do you think? 
 - patch also blocks container closing, until core loading is stopped with 
failure.
 - and also it makes run example tool spin until core is loaded before search.  
   

Concerns? 

> The Solr examples can not always be started after being stopped due to race 
> with loading core.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Priority: Critical
> Fix For: 6.6, master (7.0)
>
> Attachments: SDF init and doFilter in parallel.png, SOLR-9867.patch, 
> SOLR-9867.patch, SOLR-9867.patch, SOLR-9867-test.patch
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an 
> error when it tries to create the SolrCore (again, it already exists) and so 
> it deletes the cores instance dir which leads to tlog and index lock errors 
> in Solr.
> The reason it seems to be trying to create the core when it already exists is 
> that the run example tool uses a core status call to check existence and 
> because the core is loading, we don't consider it as existing. I added a 
> check to look for core.properties.
> That seemed to let me start up, but my first requests failed because the core 
> was still loading. It appears CoreContainer#getCore  is supposed to be 
> blocking so you don't have this problem, but there must be an issue, because 
> it is not blocking.



--
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-7810) false positive equality: distinctly diff join queries return equals()==true

[Hoss Man (JIRA)]

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

Hoss Man updated LUCENE-7810:
-
Description: 
While working on SOLR-10583 I was getting some odd test failures that seemed to 
suggest we were getting false cache hits for Join queries that should have been 
unique.

tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used to 
identify set of documents we "join from") and uses it in the equals calculation 
-- but the information about the join _field_ is never passed directly to 
{{TermsQuery}} and the BytesRefs that are passed in can't be compared 
efficiently (AFAICT), so 2 completely diff calls to 
{{JoinUtils.createJoinQuery(...)}} can result in Query objects that think they 
are {{equal()}} even when they most certainly are not.

At a brief glance, it appears that similar bugs exist in 
{{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
but i didn't look into that class at all)


  was:

While working on SOLR-10583 I was getting some odd test failures that seemed to 
suggest we were getting false cache hits for Join queries that should have been 
unique.

tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used to 
identify set of documents we "join from") and uses it in the equals calculation 
-- but the information about the join _field_ is never passed directly to 
{{TermsQuery}} and the BytesRefs that are passed in can't be compared 
efficiently (AFAICT), so 2 completely diff calls to 
{{JoinUtils.createJoinQuery(...)}} can result in Query objects that think they 
are {{equal()}} even when they most certainly are not.

At a brief glance, it appears that similar bugs exist in 
{{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
but i didn't look into that class at all)


Summary: false positive equality: distinctly diff join queries return 
equals()==true  (was: false equals() result for distinctly diff join queries)

updated summary that i realize now was value/missleading about the "false 
positive" situation.

> false positive equality: distinctly diff join queries return equals()==true
> ---
>
> Key: LUCENE-7810
> URL: https://issues.apache.org/jira/browse/LUCENE-7810
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-7810.patch
>
>
> While working on SOLR-10583 I was getting some odd test failures that seemed 
> to suggest we were getting false cache hits for Join queries that should have 
> been unique.
> tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
> implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used 
> to identify set of documents we "join from") and uses it in the equals 
> calculation -- but the information about the join _field_ is never passed 
> directly to {{TermsQuery}} and the BytesRefs that are passed in can't be 
> compared efficiently (AFAICT), so 2 completely diff calls to 
> {{JoinUtils.createJoinQuery(...)}} can result in Query objects that think 
> they are {{equal()}} even when they most certainly are not.
> At a brief glance, it appears that similar bugs exist in 
> {{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
> but i didn't look into that class at all)



--
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: Why no composite primary-key in lucene ?

[Erick Erickson]

What you haven't really explained is why you care. The only hint I see
is that you don't want to store the redundant data of your composite
key as both individual fields and a concatenated .

This feels like a whole lot of effort for no particularly good reason.
Unless you have a bazillion _very_ short docs, concatenating the parts
together in your  field is unlikely to be of measurable
consequence. If you have _measurements_ showing that's not true, it's
another story.

Assuming I'm on the right path here, I'd guess there are much more
valuable things you could spend engineering time on than the rabbit
hole of trying to work around Solr's way of dealing with 
;)..

Best,
Erick

On Sat, Apr 29, 2017 at 11:38 AM, Dorian Hoxha  wrote:
> @Yonik Thanks, makes sense.
>
> @Walter
>
> After reading the cwiki page on update request processor looks like you
> can't modify the GET/DELETE handlers, right ?
> Because I want to NOT index/store the 'id' field, so clients/solr-cloud
> (which needs /get) continue to work normally but internally 'id' appears
> only in translog.
> And I need to do something similar for GET/DELETE.
>
> How to do that ?
>
> Regards,
> Dorian
>
> On Sat, Apr 29, 2017 at 8:04 PM, Walter Underwood 
> wrote:
>>
>> If you do want a composite key in Solr, you could use an update request
>> processor script to make it out of the multiple fields.
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>>
>> On Apr 29, 2017, at 11:02 AM, Yonik Seeley  wrote:
>>
>> On Sat, Apr 29, 2017 at 1:45 PM, Dorian Hoxha 
>> wrote:
>>
>> @Yonik
>>
>> Thanks makes sense. So this means that the 'id' need to be indexed(is
>> always?), (so you can get/update/delete docs not in translog), right ?
>>
>>
>> In Solr, yes.  In Lucene, only if you want lookup-by-id to be fast, or
>> if you want to use updateDocument with an indexed term for overwriting
>> documents.
>>
>> -Yonik
>>
>>
>> On Sat, Apr 29, 2017 at 7:24 PM, Yonik Seeley  wrote:
>>
>>
>> Solr doesn't use Lucene for RT GET, it uses it's transaction log.
>> Only when the document is not found in the transaction log will it go
>> and consult the lucene index (which can only search as of the last
>> commit).
>>
>> -Yonik
>>
>> On Sat, Apr 29, 2017 at 12:57 PM, Dorian Hoxha 
>> wrote:
>>
>> I know all that. My point is, lucene is NRT, while GET is RT (in both
>> ES/SOLR). How does lucene return the right document (Term Query) before
>> doing a commit on GET ?
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

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

[jira] [Resolved] (LUCENE-7798) add equals/hashCode to ToParentBlockJoinSortField

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev resolved LUCENE-7798.
--
   Resolution: Fixed
Fix Version/s: 6.6
   master (7.0)

> add equals/hashCode to ToParentBlockJoinSortField
> -
>
> Key: LUCENE-7798
> URL: https://issues.apache.org/jira/browse/LUCENE-7798
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/join
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Fix For: master (7.0), 6.6
>
> Attachments: LUCENE-7798.patch
>
>
> Since SOLR-10521 {{ToParentBlockJoinSortField}} is going to be used as query 
> result key, therefore it's worth to implemend proper equality methods.



--
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-10521) sort by string field of the nested child when searching with {!parent}

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev resolved SOLR-10521.
-
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.6

> sort by string field of the nested child when searching with {!parent}
> --
>
> Key: SOLR-10521
> URL: https://issues.apache.org/jira/browse/SOLR-10521
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10521-6x.patch, SOLR-10521.patch, SOLR-10521.patch, 
> SOLR-10521.patch, SOLR-10521.patch, SOLR-10521-raw.patch
>
>
> The idea is to integrate Lucene's {{ToParentBlockJoinSortField}} 
> The approach to hookup -it- is -a little bit tricky-:
> -{{sort=\{!childfield bjq=$q field=COLOR_s}desc}}- 
> {{sort=\childfield(COLOR_s,) desc}}
> the question no.1 wdyt about the syntax? 
> internally it creates a function query with valueSource which produces 
> {{ToParentBlockJoinSortField}} 
> The main challenge is picking Solr field type from  
> {{ToParentBlockJoinSortField}}, because as-is it's broken on {{mergeIds}} - 
> ByteRefs need to be properly marshaled and unmarshalled by a field type from 
> the child scope. 



--
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-7041) Nuke defaultSearchField and solrQueryParser from schema

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7041: Remove a lot of defaultOperator and defaultSearchField from test 
configs (still more work to do)


> Nuke defaultSearchField and solrQueryParser from schema
> ---
>
> Key: SOLR-7041
> URL: https://issues.apache.org/jira/browse/SOLR-7041
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0
>
> Attachments: SOLR-7041-defaultOperator.patch, SOLR-7041.patch
>
>
> The two tags {{}} and {{solrQueryParser}} were deprecated 
> in Solr3.6 (SOLR-2724). Time to nuke them from code and {{schema.xml}} in 5.0?



--
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: Why no composite primary-key in lucene ?

[Dorian Hoxha]

@Yonik Thanks, makes sense.

@Walter

After reading the cwiki page on update request processor

looks like you can't modify the GET/DELETE handlers, right ?
Because I want to NOT index/store the 'id' field, so clients/solr-cloud
(which needs /get) continue to work normally but internally 'id' appears
only in translog.
And I need to do something similar for GET/DELETE.

How to do that ?

Regards,
Dorian

On Sat, Apr 29, 2017 at 8:04 PM, Walter Underwood 
wrote:

> If you do want a composite key in Solr, you could use an update request
> processor script to make it out of the multiple fields.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>
> On Apr 29, 2017, at 11:02 AM, Yonik Seeley  wrote:
>
> On Sat, Apr 29, 2017 at 1:45 PM, Dorian Hoxha 
> wrote:
>
> @Yonik
>
> Thanks makes sense. So this means that the 'id' need to be indexed(is
> always?), (so you can get/update/delete docs not in translog), right ?
>
>
> In Solr, yes.  In Lucene, only if you want lookup-by-id to be fast, or
> if you want to use updateDocument with an indexed term for overwriting
> documents.
>
> -Yonik
>
>
> On Sat, Apr 29, 2017 at 7:24 PM, Yonik Seeley  wrote:
>
>
> Solr doesn't use Lucene for RT GET, it uses it's transaction log.
> Only when the document is not found in the transaction log will it go
> and consult the lucene index (which can only search as of the last
> commit).
>
> -Yonik
>
> On Sat, Apr 29, 2017 at 12:57 PM, Dorian Hoxha 
> wrote:
>
> I know all that. My point is, lucene is NRT, while GET is RT (in both
> ES/SOLR). How does lucene return the right document (Term Query) before
> doing a commit on GET ?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

Re: Why no composite primary-key in lucene ?

[Walter Underwood]

If you do want a composite key in Solr, you could use an update request 
processor script to make it out of the multiple fields.

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


> On Apr 29, 2017, at 11:02 AM, Yonik Seeley  wrote:
> 
> On Sat, Apr 29, 2017 at 1:45 PM, Dorian Hoxha  wrote:
>> @Yonik
>> 
>> Thanks makes sense. So this means that the 'id' need to be indexed(is
>> always?), (so you can get/update/delete docs not in translog), right ?
> 
> In Solr, yes.  In Lucene, only if you want lookup-by-id to be fast, or
> if you want to use updateDocument with an indexed term for overwriting
> documents.
> 
> -Yonik
> 
> 
>> On Sat, Apr 29, 2017 at 7:24 PM, Yonik Seeley  wrote:
>>> 
>>> Solr doesn't use Lucene for RT GET, it uses it's transaction log.
>>> Only when the document is not found in the transaction log will it go
>>> and consult the lucene index (which can only search as of the last
>>> commit).
>>> 
>>> -Yonik
>>> 
>>> On Sat, Apr 29, 2017 at 12:57 PM, Dorian Hoxha 
>>> wrote:
 I know all that. My point is, lucene is NRT, while GET is RT (in both
 ES/SOLR). How does lucene return the right document (Term Query) before
 doing a commit on GET ?
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Why no composite primary-key in lucene ?

[Yonik Seeley]

On Sat, Apr 29, 2017 at 1:45 PM, Dorian Hoxha  wrote:
> @Yonik
>
> Thanks makes sense. So this means that the 'id' need to be indexed(is
> always?), (so you can get/update/delete docs not in translog), right ?

In Solr, yes.  In Lucene, only if you want lookup-by-id to be fast, or
if you want to use updateDocument with an indexed term for overwriting
documents.

-Yonik


> On Sat, Apr 29, 2017 at 7:24 PM, Yonik Seeley  wrote:
>>
>> Solr doesn't use Lucene for RT GET, it uses it's transaction log.
>> Only when the document is not found in the transaction log will it go
>> and consult the lucene index (which can only search as of the last
>> commit).
>>
>> -Yonik
>>
>> On Sat, Apr 29, 2017 at 12:57 PM, Dorian Hoxha 
>> wrote:
>> > I know all that. My point is, lucene is NRT, while GET is RT (in both
>> > ES/SOLR). How does lucene return the right document (Term Query) before
>> > doing a commit on GET ?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

Re: Why no composite primary-key in lucene ?

[Dorian Hoxha]

@Yonik

Thanks makes sense. So this means that the 'id' need to be indexed(is
always?), (so you can get/update/delete docs not in translog), right ?


On Sat, Apr 29, 2017 at 7:24 PM, Yonik Seeley  wrote:

> Solr doesn't use Lucene for RT GET, it uses it's transaction log.
> Only when the document is not found in the transaction log will it go
> and consult the lucene index (which can only search as of the last
> commit).
>
> -Yonik
>
> On Sat, Apr 29, 2017 at 12:57 PM, Dorian Hoxha 
> wrote:
> > I know all that. My point is, lucene is NRT, while GET is RT (in both
> > ES/SOLR). How does lucene return the right document (Term Query) before
> > doing a commit on GET ?
>
> -
> 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 # 3976 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, TransactionLog] 
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:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  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:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 

Re: Why no composite primary-key in lucene ?

[Yonik Seeley]

Solr doesn't use Lucene for RT GET, it uses it's transaction log.
Only when the document is not found in the transaction log will it go
and consult the lucene index (which can only search as of the last
commit).

-Yonik

On Sat, Apr 29, 2017 at 12:57 PM, Dorian Hoxha  wrote:
> I know all that. My point is, lucene is NRT, while GET is RT (in both
> ES/SOLR). How does lucene return the right document (Term Query) before
> doing a commit on GET ?

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

Re: Why no composite primary-key in lucene ?

[Dorian Hoxha]

@Erick

I know all that. My point is, lucene is NRT, while GET is RT (in both
ES/SOLR). How does lucene return the right document (Term Query) before
doing a commit on GET ?

On Sat, Apr 29, 2017 at 6:48 PM, Erick Erickson 
wrote:

> Internal magic. This is the point behind the admonitions against
> relying on the _internal_ Lucene doc ID for anything... it changes.
> For the same document. Even if the document doesn't change.
>
> Essentially when two segments are merged (and this is conceptual, not
> the code) all the live docs from the first segment are written into
> the new segments starting at 0 (or 1, like I said this is conceptual).
> This (plus the base for  the segment) is the internal lucene doc id.
> When the first segment is written, say the last internal id is 100,
> then the first live doc of the next segment gets 101. etc.
>
> Now here's the magic. The  in Solr is just some random
> field as far as Lucene is concerned. Solr knows what field this is. So
> when you try to, say, update a doc with a , _Solr_ looks
> around and asks Lucene "do you have any docs with this value in this
> field". If the answer is yes, then Solr has the internal Lucene doc ID
> and can do the right thing. So for atomic updates, Solr gets the right
> Lucene doc, pulls all the stored data from the internal Lucene doc and
> constructs another brand-new Lucene doc and applies the updates
> specified. Then Solr tells Lucene to delete the doc with the internal
> Lucene doc ID and then tells Lucene to index this new doc. Lucene
> assigns it a new internal Lucene doc ID.
>
>
> Best,
> Erick
>
> On Sat, Apr 29, 2017 at 5:38 AM, Dorian Hoxha 
> wrote:
> > Hi Shawn,
> >
> > ES has the same thing. You're right that no 'id' is needed when adding a
> > document.
> >
> > But lucene has updateDocument:
> > https://lucene.apache.org/core/6_4_0/core/org/apache/
> lucene/index/IndexWriter.html#updateDocument-org.apache.
> lucene.index.Term-java.lang.Iterable-
> > ?
> >
> > Or that doesn't need a commit before deleting docs by Term, so it can
> > atomically delete+insert  ?
> >
> > So how do solr/es connect the internal docId to the outside primary-key
> (to
> > support get,delete) ? Or by just storing/indexing the primary-key in a
> field
> > ?
> >
> > Thanks,
> > Dorian
> >
> >
> > On Fri, Apr 28, 2017 at 10:34 PM, Shawn Heisey 
> wrote:
> >>
> >> On 4/28/2017 6:16 AM, Dorian Hoxha wrote:
> >> > I searched for this on mailing-list,issues etc, but couldn't find any
> >> > post.
> >> >
> >> > So, why not have the possibility of  ?
> >> > Or nobody cared enough to implement it ? Or no gains ?
> >>
> >> To my knowledge, and I hope someone can correct me if I'm wrong, Lucene
> >> generally has absolutely no concept of a primary key at all, much less
> >> one that's composite.  At its core, Lucene won't complain if you index
> >> the same document twice -- both copies will be present.
> >>
> >> Solr (and probably a LOT of user-written Lucene code before that)
> >> introduced the concept of a uniqueKey field.  When a duplicate document
> >> is indexed to Solr, it is Solr that finds/deletes the original, not
> >> Lucene.  I feel quite confident in saying that ES has the same
> >> functionality, though I have not confirmed it.
> >>
> >> Thanks,
> >> Shawn
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

[Policeman Jenkins Server]

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

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:40128/r_h","node_name":"127.0.0.1:40128_r_h","state":"active","leader":"true"}];
 clusterState: 
DocCollection(c8n_1x3_lf//collections/c8n_1x3_lf/state.json/17)={   
"replicationFactor":"3",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:42505/r_h;,   
"core":"c8n_1x3_lf_shard1_replica2",   
"node_name":"127.0.0.1:42505_r_h"}, "core_node2":{   
"core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:40943/r_h;,   
"node_name":"127.0.0.1:40943_r_h",   "state":"down"}, 
"core_node3":{   "core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:40128/r_h;,   
"node_name":"127.0.0.1:40128_r_h",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false",   "realtimeReplicas":"1"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:40128/r_h","node_name":"127.0.0.1:40128_r_h","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//collections/c8n_1x3_lf/state.json/17)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:42505/r_h;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:42505_r_h"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:40943/r_h;,
  "node_name":"127.0.0.1:40943_r_h",
  "state":"down"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:40128/r_h;,
  "node_name":"127.0.0.1:40128_r_h",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "realtimeReplicas":"1"}
at 
__randomizedtesting.SeedInfo.seed([511AB714886B7B56:D94E88CE269716AE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:170)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

Re: Why no composite primary-key in lucene ?

[Erick Erickson]

Internal magic. This is the point behind the admonitions against
relying on the _internal_ Lucene doc ID for anything... it changes.
For the same document. Even if the document doesn't change.

Essentially when two segments are merged (and this is conceptual, not
the code) all the live docs from the first segment are written into
the new segments starting at 0 (or 1, like I said this is conceptual).
This (plus the base for  the segment) is the internal lucene doc id.
When the first segment is written, say the last internal id is 100,
then the first live doc of the next segment gets 101. etc.

Now here's the magic. The  in Solr is just some random
field as far as Lucene is concerned. Solr knows what field this is. So
when you try to, say, update a doc with a , _Solr_ looks
around and asks Lucene "do you have any docs with this value in this
field". If the answer is yes, then Solr has the internal Lucene doc ID
and can do the right thing. So for atomic updates, Solr gets the right
Lucene doc, pulls all the stored data from the internal Lucene doc and
constructs another brand-new Lucene doc and applies the updates
specified. Then Solr tells Lucene to delete the doc with the internal
Lucene doc ID and then tells Lucene to index this new doc. Lucene
assigns it a new internal Lucene doc ID.


Best,
Erick

On Sat, Apr 29, 2017 at 5:38 AM, Dorian Hoxha  wrote:
> Hi Shawn,
>
> ES has the same thing. You're right that no 'id' is needed when adding a
> document.
>
> But lucene has updateDocument:
> https://lucene.apache.org/core/6_4_0/core/org/apache/lucene/index/IndexWriter.html#updateDocument-org.apache.lucene.index.Term-java.lang.Iterable-
> ?
>
> Or that doesn't need a commit before deleting docs by Term, so it can
> atomically delete+insert  ?
>
> So how do solr/es connect the internal docId to the outside primary-key (to
> support get,delete) ? Or by just storing/indexing the primary-key in a field
> ?
>
> Thanks,
> Dorian
>
>
> On Fri, Apr 28, 2017 at 10:34 PM, Shawn Heisey  wrote:
>>
>> On 4/28/2017 6:16 AM, Dorian Hoxha wrote:
>> > I searched for this on mailing-list,issues etc, but couldn't find any
>> > post.
>> >
>> > So, why not have the possibility of  ?
>> > Or nobody cared enough to implement it ? Or no gains ?
>>
>> To my knowledge, and I hope someone can correct me if I'm wrong, Lucene
>> generally has absolutely no concept of a primary key at all, much less
>> one that's composite.  At its core, Lucene won't complain if you index
>> the same document twice -- both copies will be present.
>>
>> Solr (and probably a LOT of user-written Lucene code before that)
>> introduced the concept of a uniqueKey field.  When a duplicate document
>> is indexed to Solr, it is Solr that finds/deletes the original, not
>> Lucene.  I feel quite confident in saying that ES has the same
>> functionality, though I have not confirmed it.
>>
>> Thanks,
>> Shawn
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1289 - Still unstable

[Apache Jenkins Server]

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

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! [RawDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.RawDirectoryWrapper  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:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  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.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:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 

[jira] [Commented] (LUCENE-7514) TestLatLonPointQueries fails with biased (evil) numbers

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7514:
-

Didn't look, but I once replaced float generation with "biased" floats and it 
was relatively easy to break other geo tests too.

> TestLatLonPointQueries fails with biased (evil) numbers
> ---
>
> Key: LUCENE-7514
> URL: https://issues.apache.org/jira/browse/LUCENE-7514
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Priority: Minor
> Attachments: LUCENE-7514.patch
>
>
> After I commit LUCENE-7513 and switch to evil numbers, some tests fail in 
> TestLatLonPointQueries. Could be I made a mistake somewhere in BiasedNumbers, 
> but a verification would be nice.
> Example failing seed: 
> -Dtests.seed=B6740F75309ABA5D
> but it fails with multiple seeds, actually. The output for the seed above:
> {code}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLatLonPointQueries -Dtests.method=testAllLatEqual 
> -Dtests.seed=B6740F75309ABA5D -Dtests.slow=true -Dtests.locale=lv-LV 
> -Dtests.timezone=Antarctica/McMurdo -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.42s | TestLatLonPointQueries.testAllLatEqual <<<
>[junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
> possibly more):
>[junit4]> FAIL: id=6 should not match but did
>[junit4]>   box=Rectangle(lat=0.0 TO 1.401298464324817E-45 
> lon=179.97 TO 180.0)
>[junit4]>   query=point:[0.0 TO 0.0],[179.9991618097 TO 
> 179.9991618097] docID=6
>[junit4]>   lat=0.0 lon=179.9991618097
>[junit4]>   deleted?=false
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([B6740F75309ABA5D:BE159FB39579850]:0)
>[junit4]>at 
> org.apache.lucene.geo.BaseGeoPointTestCase.verifyRandomRectangles(BaseGeoPointTestCase.java:858)
>[junit4]>at 
> org.apache.lucene.geo.BaseGeoPointTestCase.verify(BaseGeoPointTestCase.java:740)
>[junit4]>at 
> org.apache.lucene.geo.BaseGeoPointTestCase.testAllLatEqual(BaseGeoPointTestCase.java:449)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id=FST50}, docValues:{id=DocValuesFormat(name=Asserting), 
> point=DocValuesFormat(name=Direct)}, maxPointsInLeafNode=1823, 
> maxMBSortInHeap=7.309388819818781, sim=RandomSimilarity(queryNorm=false): {}, 
> locale=lv-LV, timezone=Antarctica/McMurdo
>[junit4]   2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 1.8.0_102 
> (64-bit)/cpus=8,threads=1,free=182766440,total=257425408
>[junit4]   2> NOTE: All tests run in this JVM: [TestLatLonPointQueries]
>[junit4] Completed [1/1 (1!)] in 1.98s, 1 test, 1 failure <<< FAILURES!
> {code}



--
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-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+164) - Build # 19512 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19512/
Java: 32bit/jdk-9-ea+164 -server -XX:+UseParallelGC

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, 
TransactionLog, MockDirectoryWrapper] 
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:1184)  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.base/java.lang.Thread.run(Thread.java:844)  
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:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  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.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
expected:<3> but was:<1>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([BB3D66F3A363F2AD:F3481247A550DD38]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:530)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11693 lines...]
   [junit4] Suite: 

[jira] [Commented] (LUCENE-7807) Test*RangeFieldQueries.testRandomBig() and .testRandomTiny() failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7807:


ASF Jenkins found another reproducing seed for {{testRandomTiny()}} failures 
[https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1288]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestLongRangeFieldQueries -Dtests.method=testRandomTiny 
-Dtests.seed=69A0759E7B6AFB0B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=th-TH-u-nu-thai-x-lvariant-TH -Dtests.timezone=Asia/Jerusalem 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.10s J2 | TestLongRangeFieldQueries.testRandomTiny <<<
   [junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
possibly more):
   [junit4]> FAIL (iter 87): id=0 should not match but did
   [junit4]>  queryRange=Box(-9223372036854775808 TO 9223372036854775807)
   [junit4]>  box=Box(-5634937821465863869 TO 6781131293060666383)
   [junit4]>  queryType=CONTAINS
   [junit4]>  deleted?=false
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([69A0759E7B6AFB0B:20E7ABD8254BC3A7]:0)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:158)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomTiny(BaseRangeFieldQueryTestCase.java:64)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{id=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128)))},
 docValues:{id=DocValuesFormat(name=Lucene70), 
longRangeField=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=1325, 
maxMBSortInHeap=5.728447065351258, sim=RandomSimilarity(queryNorm=false): {}, 
locale=th-TH-u-nu-thai-x-lvariant-TH, timezone=Asia/Jerusalem
   [junit4]   2> NOTE: Linux 3.13.0-88-generic amd64/Oracle Corporation 
1.8.0_121 (64-bit)/cpus=4,threads=1,free=104683560,total=353370112
{noformat}

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestDoubleRangeFieldQueries -Dtests.method=testRandomTiny 
-Dtests.seed=69A0759E7B6AFB0B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=hu-HU -Dtests.timezone=Asia/Kuala_Lumpur -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.04s J0 | TestDoubleRangeFieldQueries.testRandomTiny <<<
   [junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
possibly more):
   [junit4]> FAIL (iter 87): id=0 should not match but did
   [junit4]>  queryRange=Box(-Infinity TO Infinity)
   [junit4]>  box=Box(4.992828343822847E307 TO 7.931369402719117E307)
   [junit4]>  queryType=CONTAINS
   [junit4]>  deleted?=false
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([69A0759E7B6AFB0B:20E7ABD8254BC3A7]:0)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:158)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomTiny(BaseRangeFieldQueryTestCase.java:64)
[...]
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=RandomSimilarity(queryNorm=false): {}, locale=hu-HU, 
timezone=Asia/Kuala_Lumpur
   [junit4]   2> NOTE: Linux 3.13.0-88-generic amd64/Oracle Corporation 
1.8.0_121 (64-bit)/cpus=4,threads=1,free=288978264,total=373817344
{noformat}

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestFloatRangeFieldQueries -Dtests.method=testRandomTiny 
-Dtests.seed=69A0759E7B6AFB0B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-AE -Dtests.timezone=US/Eastern -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.01s J2 | TestFloatRangeFieldQueries.testRandomTiny <<<
   [junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
possibly more):
   [junit4]> FAIL (iter 87): id=0 should not match but did
   [junit4]>  queryRange=Box(-Infinity TO Infinity)
   [junit4]>  box=Box(-1.1309494E38 TO 1.5677334E38)
   [junit4]>  queryType=CONTAINS
   [junit4]>  deleted?=false
   [junit4]>at 

Re: Release 6.6

[Martin Gainty]

Martin Gainty has shared a OneDrive file with you. To view it, click the link 
below.



[https://r1.res.office365.com/owa/prem/images/dc-generic_20.png]

TestPayloadCheckQuery.java




attached


I coded this last nite so it is "quick and dirty"

in any case let me know if  testSpanPayloadCheck() method modification properly 
addresses your situation


Thanks!

Martin
__




From: Erik Hatcher 
Sent: Saturday, April 29, 2017 8:58 AM
To: dev@lucene.apache.org
Subject: Re: Release 6.6

Martin - there is a test class specifically for this query.   See the recent 
commits I've made to test it further fixing .equals/.hashCode and rewrite.

Can you send your full test code?

   Erik

On Apr 29, 2017, at 07:32, Martin Gainty 
> wrote:


when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was about to 
reply just run that TestCase
(until i discovered there wasnt any!)


i'll start the bidding at 1 dinar for TestCase 
org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:

  @org.junit.Test
  public void testSpanPayloadCheck() throws Exception


//now lets test the collectLeaf for query
//of course calling Base Class SpanPayloadCheckQuery to construct query

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where position="+position);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);

try
{ //test public void collectLeaf(org.apache.lucene.index.PostingsEnum 
postings, int position,  //org.apache.lucene.index.Term term) 
throws java.io.IOException {
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1);
}
catch(java.io.IOException ioe) { 
log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws IOException 
="+ioe.getMessage()); }


unless of course anyone has a better idea to test collectLeaf ?

Martin
__




From: Erik Hatcher >
Sent: Tuesday, April 25, 2017 7:57 PM
To: dev@lucene.apache.org
Subject: Re: Release 6.6

Probably no bribe needed, but an updated patch would be a good start (or will 
the 2.5 year old patch still apply and be acceptable as-is?)

Erik

On Apr 25, 2017, at 7:52 PM, Walter Underwood 
> wrote:

Who do I have to bribe to get SOLR-629 included?

https://issues.apache.org/jira/browse/SOLR-629

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


On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya 
> wrote:

Hi,
We have lots of changes, optimizations, bug fixes for 6.6. I'd like to propose 
a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0 release).

I can volunteer to release this, and I can cut the release branch around 4th 
May, in order to let some time for devs to finish current issues.

What do you think?

Regards,
Ishan

Re: Release 6.6

[Erik Hatcher]

Martin - there is a test class specifically for this query.   See the recent 
commits I've made to test it further fixing .equals/.hashCode and rewrite. 

Can you send your full test code?

   Erik

> On Apr 29, 2017, at 07:32, Martin Gainty  wrote:
> 
> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was about 
> to reply just run that TestCase
> (until i discovered there wasnt any!)
> 
> 
> i'll start the bidding at 1 dinar for TestCase 
> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
> 
>   @org.junit.Test
>   public void testSpanPayloadCheck() throws Exception
> 
> 
> 
> //now lets test the collectLeaf for query
> //of course calling Base Class SpanPayloadCheckQuery to construct query
> 
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before 
> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>  (int)position,(org.apache.lucene.index.Term)term1) where 
> postings="+postings);
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before 
> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>  (int)position,(org.apache.lucene.index.Term)term1) where 
> position="+position);
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before 
> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>  (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
> 
> try
> { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum 
> postings, int position,  //org.apache.lucene.index.Term term) 
> throws java.io.IOException {
> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>  (int)position,(org.apache.lucene.index.Term)term1);
> }
> catch(java.io.IOException ioe) { 
> log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 
> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>  (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws 
> IOException ="+ioe.getMessage()); }
> 
> unless of course anyone has a better idea to test collectLeaf ?
> 
> Martin 
> __ 
> 
> 
> 
> From: Erik Hatcher 
> Sent: Tuesday, April 25, 2017 7:57 PM
> To: dev@lucene.apache.org
> Subject: Re: Release 6.6
>  
> Probably no bribe needed, but an updated patch would be a good start (or will 
> the 2.5 year old patch still apply and be acceptable as-is?)
> 
> Erik
> 
>> On Apr 25, 2017, at 7:52 PM, Walter Underwood  wrote:
>> 
>> Who do I have to bribe to get SOLR-629 included?
>> 
>> https://issues.apache.org/jira/browse/SOLR-629
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>> 
>> 
>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya 
>>>  wrote:
>>> 
>>> Hi,
>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd like to 
>>> propose a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0 
>>> release).
>>> 
>>> I can volunteer to release this, and I can cut the release branch around 
>>> 4th May, in order to let some time for devs to finish current issues.
>>> 
>>> What do you think?
>>> 
>>> Regards,
>>> Ishan
>>> 
>> 
> 

Re: Why no composite primary-key in lucene ?

[Dorian Hoxha]

Hi Shawn,

ES has the same thing. You're right that no 'id' is needed when adding a
document.

But lucene has updateDocument: https://lucene.apache.org/core
/6_4_0/core/org/apache/lucene/index/IndexWriter.html#updateD
ocument-org.apache.lucene.index.Term-java.lang.Iterable- ?

Or that doesn't need a commit before deleting docs by Term, so it can
atomically delete+insert  ?

So how do solr/es connect the internal docId to the outside primary-key (to
support get,delete) ? Or by just storing/indexing the primary-key in a
field ?

Thanks,
Dorian


On Fri, Apr 28, 2017 at 10:34 PM, Shawn Heisey  wrote:

> On 4/28/2017 6:16 AM, Dorian Hoxha wrote:
> > I searched for this on mailing-list,issues etc, but couldn't find any
> > post.
> >
> > So, why not have the possibility of  ?
> > Or nobody cared enough to implement it ? Or no gains ?
>
> To my knowledge, and I hope someone can correct me if I'm wrong, Lucene
> generally has absolutely no concept of a primary key at all, much less
> one that's composite.  At its core, Lucene won't complain if you index
> the same document twice -- both copies will be present.
>
> Solr (and probably a LOT of user-written Lucene code before that)
> introduced the concept of a uniqueKey field.  When a duplicate document
> is indexed to Solr, it is Solr that finds/deletes the original, not
> Lucene.  I feel quite confident in saying that ES has the same
> functionality, though I have not confirmed it.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (LUCENE-7737) Remove spatial-extras dependency on queries

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-7737:
-
Fix Version/s: master (7.0)

> Remove spatial-extras dependency on queries
> ---
>
> Key: LUCENE-7737
> URL: https://issues.apache.org/jira/browse/LUCENE-7737
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial-extras
>Reporter: Alan Woodward
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: LUCENE-7737.patch
>
>
> The spatial-extras module uses ValueSources for a number of different 
> purposes, requiring a dependency on the queries module.  I'd like to try 
> using core-only interfaces here instead, allowing us to remove the dependency



--
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-7741) Add explain() to DoubleValues

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7741:
--

+1 looks great!

* What is "NB " in the comments?
* testExplanations tests nothing?  Or was your intention just a lack of 
exceptions?

> Add explain() to DoubleValues
> -
>
> Key: LUCENE-7741
> URL: https://issues.apache.org/jira/browse/LUCENE-7741
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: LUCENE-7741.patch
>
>
> As noted on LUCENE-7737, it would be nice to be able to get an explanation 
> for DoubleValues values, particularly for things like complex spatial 
> distance calculations.



--
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-7719) UnifiedHighlighter doesn't handle some AutomatonQuery's with multi-byte chars

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7719:
--

[~mikemccand] What do you think of the patch?  In particular, I wonder what you 
think of:
* AutomatonQuery.isAutomatonBinary().  This is a very simple/innocent addition. 
 It's a shame Automaton.isBinary (or something similar) doesn't exist.  
* See my TODO last paragraph above.  Also note even if that were done, the 
CompiledAutomaton isn't exposed by AutomatonQuery any way; so we'd need an 
accessor.  Perhaps alternatively AutomatonQuery might expose both a 
CharRunAutomaton and ByteRunAutomaton (i.e. move some of the code in this patch 
to there)?  If that wouldn't potentially be useful to other users then 
nevermind.
* The approach to convert chars to bytes at each step


> UnifiedHighlighter doesn't handle some AutomatonQuery's with multi-byte chars
> -
>
> Key: LUCENE-7719
> URL: https://issues.apache.org/jira/browse/LUCENE-7719
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE_7719.patch
>
>
> In MultiTermHighlighting, a CharacterRunAutomaton is being created that takes 
> the result of AutomatonQuery.getAutomaton that in turn is byte oriented, not 
> character oriented.  For ASCII terms, this is safe but it's not for 
> multi-byte characters.  This is most likely going to rear it's head with a 
> WildcardQuery, but due to special casing in MultiTermHighlighting, 
> PrefixQuery isn't affected.  Nonetheless it'd be nice to get a general fix in 
> so that MultiTermHighlighting can remove special cases for PrefixQuery and 
> TermRangeQuery (both subclass AutomatonQuery).
> AFAICT, this bug was likely in the PostingsHighlighter since inception.



--
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-7719) UnifiedHighlighter doesn't handle some AutomatonQuery's with multi-byte chars

[David Smiley (JIRA)]

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

David Smiley edited comment on LUCENE-7719 at 4/29/17 12:19 PM:


Here is a patch for consideration.

First of all, I realized that this bug is very minor because only _some_ 
{{AutomatonQuery.getAutomaton}} are binary (I thought they all were); others 
are char based.  The ones that are binary in Lucene are {{PrefixQuery}} and 
{{TermRangeQuery}}, both of which are special cased in 
{{MultiTermHighlighting}}.  So practically speaking I think the only users to 
see this bug would be anyone building a custom AutomatonQuery.  Nonetheless 
this should be cleaned up and actually tested.

The patch:
* Adds a fairly thorough test with lots of randomized unicode, testing 
PrefixQuery, TermRangeQuery, WildcardQuery, and FuzzyQuery
* removes the special casing of AutomatonQuery subclasses in 
MultiTermHighlighting.  AQ is handled generically now.
* added {{AutomatonQuery.isAutomatonBinary()}} with a new field to match.
* if the AQ.getAutomaton is _not_ binary, we follow a simple/obvious path
* if the automaton is binary, then I produce a CharRunAutomaton implementing 
run() to navigate the Automaton char by char.  It makes a BytesRunAutomaton on 
the automaton.  I inlined the one and two byte UTF char logic from 
{{UnicodeUtil.UTF16toUTF8}}.  If the char needs more bytes, then I call out to 
UTF16toUTF8 and work off the generated byte array for the remaining chars.  I 
think this is more maintainable, albeit slower, than reproducing the logic.

I added a perf TODO in MultiTermHighlighting.java to have CompiledAutomaton 
expose the ByteRunAutomaton so that we don't need to rebuild it here.  The 
construction cost seems less than trivial as it determinizes the automaton and 
does other work.  Is this a big deal?  It seems kinda sorta; it depends.  


was (Author: dsmiley):
Here is a patch for consideration.

First of all, I realized that this bug is very minor because only _some_ 
{{AutomatonQuery.getAutomaton}} are binary (I thought they all were); others 
are char based.  The ones that are binary in Lucene are {{PrefixQuery}} and 
{{TermRangeQuery}}, both of which are special cased in 
{{MultiTermHighlighting}}.  So practically speaking I think the only users to 
see this bug would be anyone building a custom AutomatonQuery.  Nonetheless 
this should be cleaned up and actually tested.

The patch:
* Adds a fairly thorough test with lots of randomized unicode, testing 
PrefixQuery, TermRangeQuery, WildcardQuery, and FuzzyQuery
* removes the special casing of AutomatonQuery subclasses in 
MultiTermHighlighting.  AQ is handled generically now.
* added {{AutomatonQuery.isAutomatonBinary()}} with a new field to match.
* if the AQ.getAutomaton is _not_ binary, we follow a simple/obvious path
* if the automaton is binary, then I produce a CharRunAutomaton implementing 
run() to navigate the Automaton char by char.  It makes a BytesRunAutomaton on 
the automaton.  I inlined the one and two byte UTF char logic from 
{{UnicodeUtil.UTF16toUTF8}}.  If the char needs more bytes, then I call out to 
UTF16toUTF8 and work off the generated byte array for the remaining chars.  I 
think this is more maintainable, albeit slower, than reproducing the logic.

There is a TODO on making the BytesRunAutomaton on the binary Automaton.  This 
is redundant since the AutomatonQuery already has a compiledAutomaton which in 
turn already has a BytesRunAutomaton.  The construction cost seems less than 
trivial as it determinizes the automaton and does other work.  Is this a big 
deal?  It seems kinda sorta; it depends.  

> UnifiedHighlighter doesn't handle some AutomatonQuery's with multi-byte chars
> -
>
> Key: LUCENE-7719
> URL: https://issues.apache.org/jira/browse/LUCENE-7719
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE_7719.patch
>
>
> In MultiTermHighlighting, a CharacterRunAutomaton is being created that takes 
> the result of AutomatonQuery.getAutomaton that in turn is byte oriented, not 
> character oriented.  For ASCII terms, this is safe but it's not for 
> multi-byte characters.  This is most likely going to rear it's head with a 
> WildcardQuery, but due to special casing in MultiTermHighlighting, 
> PrefixQuery isn't affected.  Nonetheless it'd be nice to get a general fix in 
> so that MultiTermHighlighting can remove special cases for PrefixQuery and 
> TermRangeQuery (both subclass AutomatonQuery).
> AFAICT, this bug was likely in the PostingsHighlighter since inception.



--
This message was sent by Atlassian 

[JENKINS] Lucene-Solr-Tests-master - Build # 1785 - Still Unstable

[Apache Jenkins Server]

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

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
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.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:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  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:1184)  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.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 

[jira] [Commented] (LUCENE-7798) add equals/hashCode to ToParentBlockJoinSortField

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7798: Add .equals and .hashCode to ToParentBlockJoinSortField


> add equals/hashCode to ToParentBlockJoinSortField
> -
>
> Key: LUCENE-7798
> URL: https://issues.apache.org/jira/browse/LUCENE-7798
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/join
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Attachments: LUCENE-7798.patch
>
>
> Since SOLR-10521 {{ToParentBlockJoinSortField}} is going to be used as query 
> result key, therefore it's worth to implemend proper equality methods.



--
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: Release 6.6

[Martin Gainty]

when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was about to 
reply just run that TestCase
(until i discovered there wasnt any!)


i'll start the bidding at 1 dinar for TestCase 
org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:

  @org.junit.Test
  public void testSpanPayloadCheck() throws Exception


//now lets test the collectLeaf for query
//of course calling Base Class SpanPayloadCheckQuery to construct query

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where position="+position);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);

try
{ //test public void collectLeaf(org.apache.lucene.index.PostingsEnum 
postings, int position,  //org.apache.lucene.index.Term term) 
throws java.io.IOException {
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1);
}
catch(java.io.IOException ioe) { 
log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws IOException 
="+ioe.getMessage()); }


unless of course anyone has a better idea to test collectLeaf ?

Martin
__




From: Erik Hatcher 
Sent: Tuesday, April 25, 2017 7:57 PM
To: dev@lucene.apache.org
Subject: Re: Release 6.6

Probably no bribe needed, but an updated patch would be a good start (or will 
the 2.5 year old patch still apply and be acceptable as-is?)

Erik

On Apr 25, 2017, at 7:52 PM, Walter Underwood 
> wrote:

Who do I have to bribe to get SOLR-629 included?

https://issues.apache.org/jira/browse/SOLR-629

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


On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya 
> wrote:

Hi,
We have lots of changes, optimizations, bug fixes for 6.6. I'd like to propose 
a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0 release).

I can volunteer to release this, and I can cut the release branch around 4th 
May, in order to let some time for devs to finish current issues.

What do you think?

Regards,
Ishan

[jira] [Commented] (LUCENE-7798) add equals/hashCode to ToParentBlockJoinSortField

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7798: Add .equals and .hashCode to ToParentBlockJoinSortField


> add equals/hashCode to ToParentBlockJoinSortField
> -
>
> Key: LUCENE-7798
> URL: https://issues.apache.org/jira/browse/LUCENE-7798
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/join
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Attachments: LUCENE-7798.patch
>
>
> Since SOLR-10521 {{ToParentBlockJoinSortField}} is going to be used as query 
> result key, therefore it's worth to implemend proper equality methods.



--
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-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+164) - Build # 19511 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19511/
Java: 32bit/jdk-9-ea+164 -client -XX:+UseG1GC

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

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([7666D05992B154EB:140B2E185D3F34D5]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at 
org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter(MetricsHandlerTest.java:201)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 12782 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.MetricsHandlerTest
   [junit4]   2> Creating dataDir: 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxDocs

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([7D57302EABBD9DDA:C4D6E6F187579950]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:896)
at 
org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


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




Build Log:
[...truncated 12129 lines...]
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 335 - Unstable

[Apache Jenkins Server]

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

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

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)  
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110)  at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108)
  at sun.reflect.GeneratedConstructorAccessor186.newInstance(Unknown Source)  
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  at 
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:759)  at 
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:821)  at 
org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1078)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:942)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:829)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:916)  at 
org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:555)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [HdfsTransactionLog]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110)
at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108)
at sun.reflect.GeneratedConstructorAccessor186.newInstance(Unknown 
Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:759)
at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:821)
at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1078)
at org.apache.solr.core.SolrCore.(SolrCore.java:942)
at org.apache.solr.core.SolrCore.(SolrCore.java:829)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:916)
at 
org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:555)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


at __randomizedtesting.SeedInfo.seed([4719030EA5AB0CD1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:302)
at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19510/
Java: 64bit/jdk1.8.0_121 -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, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog] 
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:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  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.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:1184)  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: