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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-6630 at 4/19/17 4:29 AM:
-

I'd like to have this in by 7.0. Another alternative to "manual" that came to 
mind was "custom".

Edit: Marking this a blocker so as to keep track of things to do before we 
release 7.0. If this was not appropriate, please let me know / unmark as 
blocker.


was (Author: ichattopadhyaya):
I'd like to have this in by 7.0. Another alternative to "manual" that came to 
mind was "custom".

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



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

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

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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-6630:
---
Priority: Blocker  (was: Major)

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



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

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

[jira] [Commented] (SOLR-8668) Remove support for (in favour of )

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8668:


+1, thanks for working on this.

bq. do we need to throw an exception if anyone still configures  
or is it fair to silently ignore it
I think a warning might be a fair compromise, instead of an exception or silent 
ignoring.

> Remove support for  (in favour of )
> 
>
> Key: SOLR-8668
> URL: https://issues.apache.org/jira/browse/SOLR-8668
> Project: Solr
>  Issue Type: Improvement
>Reporter: Shai Erera
>Priority: Blocker
> Fix For: master (7.0)
>
>
> Following SOLR-8621, we should remove support for {{}} (and 
> related {{}} and {{}}) in trunk/6x.



--
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-6630) Deprecate the "implicit" router and rename to "manual"

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-6630:
---
Affects Version/s: (was: 4.10)
Fix Version/s: (was: 6.0)
   (was: 5.0)
   master (7.0)

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



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

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

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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-6630:


I'd like to have this in by 7.0. Another alternative to "manual" that came to 
mind was "custom".

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



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

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

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

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9824:


How about this gets committed for Solr 6.6?

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



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

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

[jira] [Commented] (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=15973930#comment-15973930
 ] 

Erick Erickson commented on SOLR-10519:
---

Or maybe just use componentName. If that works for me I'll close this JIRA.


> 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
>
>
> 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] [Updated] (SOLR-1485) Payload scoring support

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-1485:
---
Attachment: SOLR-1485.patch

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

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



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=6194, name=jetty-launcher-1005-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=6194, name=jetty-launcher-1005-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
at __randomizedtesting.SeedInfo.seed([5D8258210888F519]:0)




Build Log:
[...truncated 11958 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_5D8258210888F519-001/init-core-data-001
   [junit4]   2> 696855 WARN  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[5D8258210888F519]-worker) [   
 ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=6 numCloses=6
   [junit4]   2> 696855 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[5D8258210888F519]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Using TrieFields
   [junit4]   2> 696857 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[5D8258210888F519]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 696907 WARN  

[jira] [Updated] (SOLR-1485) Payload scoring support

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-1485:
---
Attachment: SOLR-1485.patch

last patch had a recursive loop issue on the SimScorer ({{this}} instead of the 
delegate)

> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, 
> SOLR-1485.patch, SOLR-1485.patch, SOLR-1485.patch
>
>
> Solr 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-10396) Implement trigger support for nodeLost event type

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-10396:

Attachment: SOLR-10396.patch

Patch for this ticket.

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



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

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

[jira] [Updated] (SOLR-10516) Add eval Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10516:
--
Summary: Add eval Streaming Expression  (was: Add eval() Streaming 
Expression)

> Add eval Streaming Expression
> -
>
> Key: SOLR-10516
> URL: https://issues.apache.org/jira/browse/SOLR-10516
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10516.patch, SOLR-10516.patch
>
>
> The eval() Streaming Expression reads a single tuple from an underlying 
> stream and looks in the expr_s field for an expression to compile and run. 
> eval emits the tuples from the expression that it compiles. 
> This allows streaming expressions to write streaming expressions and have 
> them evaluated.
> Syntax:
> {code}
> eval(expr)
> {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

[jira] [Commented] (SOLR-10516) Add eval() Streaming Expression

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10516:


Commit 48d54ac45860a1b75bfd79aaffe9d4d24c2ad5a8 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=48d54ac ]

SOLR-10516: Add eval() Streaming Expression


> Add eval() Streaming Expression
> ---
>
> Key: SOLR-10516
> URL: https://issues.apache.org/jira/browse/SOLR-10516
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10516.patch, SOLR-10516.patch
>
>
> The eval() Streaming Expression reads a single tuple from an underlying 
> stream and looks in the expr_s field for an expression to compile and run. 
> eval emits the tuples from the expression that it compiles. 
> This allows streaming expressions to write streaming expressions and have 
> them evaluated.
> Syntax:
> {code}
> eval(expr)
> {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] Lucene-Solr-Tests-master - Build # 1775 - Unstable

[Apache Jenkins Server]

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

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

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([99AD8954415D9E27:237FE62CC2737032]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:896)
at 
org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:353)
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:529=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:889)
... 40 more




Build Log:
[...truncated 11606 lines...]
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-10338) Configure SecureRandom non blocking for tests.

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10338:
-

I don't think we should have tests that assert something happens "fast enough" 
... past experience shows that leads nothing but pain.

I think for a check like this, it's fine to just be more permissive about the 
expected types of non-blocking algorithms we might encounter -- as long as 
there's an easy work around for people on a the bleeding edge of 
new/alternative JVMs.

how about something like ...

{code}
final String egdfile = System.getProperty("java.security.egd");
final String allowed = System.getProperty("test.solr.allowed.securerandom");

// NOTE: we're checking egdfile *BEFORE* we init a SecureRandom, since we 
want this check to
// be as fast as possible, and if it's not correct, the SecureRandom 
constructor might block and slow us down
if (null == allowed) {
  assertEquals("Solr tests expect a non-blocking SecureRandom to be 
configured. " +
   "Use -Djava.security.egd=file:/dev/./urandom as a JVM option 
when running tests to bypass this check.",
   "file:/dev/./urandom", egdfile);
}

final String actual = (new SecureRandom()).getAlgorithm();

if (null != allowed) {
  assertEquals("SecureRandom algorithm does not match the specified 
-Dtest.solr.allowed.securerandom=" + allowed + " JVM option. " +
   "Set -Djava.security.egd=... accordingly, or remove the 
test.solr.allowed.securerandom option",
   allowed, actual);
} else {
  assertTrue("SecureRandom algorithm '"+actual+"' is in use by your JVM, " +
 "but does not match any of the known non-blocking algorithms 
that are expected. " +
 "Please report the details of this failure (and your JVM 
vendor/version) to solr-u...@lucene.apache.org. " +
 "You can bypass this check in the meantime by specifying 
-Dtest.solr.allowed.securerandom=" +
 actual + " as a JVM option when running tests.",
 // be permissive in our checks to try and account for future 
variations
 (actual.contains("NonBlocking") || actual.contains("SHA") || 
actual.contains("DRBG")));
}

{code}




> Configure SecureRandom non blocking for tests.
> --
>
> Key: SOLR-10338
> URL: https://issues.apache.org/jira/browse/SOLR-10338
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mihaly Toth
>Assignee: Mark Miller
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we 
> could get rid of random entropy exhaustion issue related to all usages of 
> SecureRandom.



--
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=15973770#comment-15973770
 ] 

Erick Erickson commented on SOLR-10519:
---

I suppose an alternative would be when looking for the child if it isn't found 
without the slash, prepend the slash but I really don't like alternative.

> 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
>
>
> 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] [Updated] (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:all-tabpanel
 ]

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

it's kind of hard to read from the patch, but all it does is make
public static Object atPath(String jsonPath, Map json)
call
public static Object atPath(String jsonPath, Map json, String 
delim) 

with "/" as the delim. Now I can call something like:
SolrCLI.atPath("#config#requestHandler#/query#defaults#wt", configJson, "#");

and get the wt parameter for this request handler.

I suppose one could also escape the slash somehow, but this works. I'll commit 
this relatively soon unless there are objections (after precommit and testing 
of course, which I haven't done yet).

> 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
>
>
> 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] [Updated] (SOLR-10516) Add eval() Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10516:
--
Attachment: SOLR-10516.patch

Added a simple test case

> Add eval() Streaming Expression
> ---
>
> Key: SOLR-10516
> URL: https://issues.apache.org/jira/browse/SOLR-10516
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10516.patch, SOLR-10516.patch
>
>
> The eval() Streaming Expression reads a single tuple from an underlying 
> stream and looks in the expr_s field for an expression to compile and run. 
> eval emits the tuples from the expression that it compiles. 
> This allows streaming expressions to write streaming expressions and have 
> them evaluated.
> Syntax:
> {code}
> eval(expr)
> {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

[jira] [Created] (SOLR-10519) SolrCLI.atPath cannot handle children that begin with a slash.

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-10519:
-

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


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-10439) SchemaField.getNamedPropertyValues doesn't include 'large'

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10439:
-

1) created SOLR-10518 with some ideas on a whitebox coverage test to ensure 
bugs like this don't bite us in the future.

2) i haven't tested this personally, but isn't "large" also missing from the 
code for {{/schema/fieldtypes}} ? and possibly {{/schema/dynamicfields}} ? 

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



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

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

[jira] [Created] (SOLR-10518) Need whitebox testing of FieldProperties constants & SchemaField.getNamedPropertyValues(true)

[Hoss Man (JIRA)]

Hoss Man created SOLR-10518:
---

 Summary: Need whitebox testing of FieldProperties constants & 
SchemaField.getNamedPropertyValues(true)
 Key: SOLR-10518
 URL: https://issues.apache.org/jira/browse/SOLR-10518
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


SOLR-10439 is an example of a bug in 
{{SchemaField.getNamedPropertyValues(true)}} that could have been caught if we 
had an automated whitebox test of all known field properties.

we should add some tests to ensure future bugs like this don't surprise us 
again...

* add a {{static FieldPropertiesExposer extends FieldProperties}}
** include a new method to use reflection to expose all {{protected final 
static int}} constants inherited from {{FieldProperties}}
** include new public methods to expose {{propertyNames\[\]}} 
{{propertyNameToInt(String)}} and {{getPropertyName(int)}}
* assert that the number int constants is the same as {{propertyNames.size}}
* loop over all property names and confirm a round trip of 
{{getPropertyName(propertyNameToInt(name))}}
* loop over all constnats and confirm a round trip of 
{{propertyNameToInt(getPropertyName(constant))}}
* use the IndexSchema (pointed at some relatively robust kitchen sink of a 
schema.xml) to loop over every {{FieldType}}, {{SchemaField}} and 
{{DynamicField.getPrototype()}}:
** for each one, verify that {{getNamedPropertyValues(true)}} returns a map 
with {{size()==FieldPropertiesExposer.propertyNames.length}}
*** minus any special cases that are deliberaly excuded, like BINARY.



--
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: lucene-solr:master: SOLR-10439: 'large' was forgotten in /schema/fields?showDefaults=true

[Chris Hostetter]

David: doesn't this same bug affect /schema/fieldType ? 

Can't large="true" be specified on fieldType as a default for all fields 
that inherit from that type?

Also: what about /schema/dynamicfields ?




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

[jira] [Created] (SOLR-10517) It would be nice to have a way to insure that config and schema API calls have propagated to all cores

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-10517:
-

 Summary: It would be nice to have a way to insure that config and 
schema API calls have propagated to all cores
 Key: SOLR-10517
 URL: https://issues.apache.org/jira/browse/SOLR-10517
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.5, master (7.0)
Reporter: Erick Erickson


While working on SOLR-10493 I discovered that the test was failing because a 
config change had been made. That test goes on to delete collections, but the 
config change is still sending out reload commands. The sequence is something 
like this:

1> config change request is made.
2> call returns, but various core reload commands are still being sent out
3> collection is deleted
4> one of the reloads from <2> arrives

Test fails because the core (and descriptor) is gone.

This was succeeding before SOLR-10007 because (I think) there was a copy of the 
coreDescriptor being held in several places and one of the un-deleted ones was 
being used.

It would be good if there were a way to be sure that that config and schema 
calls had been propagated to all replicas in all affected collections.




--
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-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-9555:

Attachment: SOLR-9555-WIP-3.patch

Looking at the {{ForceLeaderTest}} code snippet that you posted, 
[~markrmil...@gmail.com], I don't think we can reorder to kill the leader 
first. We close the followers' connections, and then need to send a doc so that 
it can fail to distribute and that is what triggers the LIR. So I get the 
impression that closing a proxy only prevents inbound connections, not outbound 
connections, which is why the followers are able to recover gracefully. 
Interestingly, removing the 2 second sleep allows the test to pass for me, and 
I can't see how it invalidates the premises under test here.

Intermittently, {{ForceLeaderTest::testReplicasInLIRNoLeader}} will still fail 
for me, and I haven't figured that one out yet since I haven't caught it with a 
reproducible seed yet.

I've had a few more other test failures in the total suite, but I think this 
patch is getting close to finished.

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



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

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

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

[Policeman Jenkins Server]

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

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

[jira] [Commented] (SOLR-9515) Update to Hadoop 3

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9515:


[~markrmil...@gmail.com] Should we create sub-tasks as we identify new issues? 
e.g. after alpha1, alpha2 etc. That will keep individual patches simpler to 
review and apply. I have already done this for security related changes (Ref: 
SOLR-9761).

> Update to Hadoop 3
> --
>
> Key: SOLR-9515
> URL: https://issues.apache.org/jira/browse/SOLR-9515
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-9515.patch
>
>
> Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. 
> I'll start up a dev branch.



--
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-10472) Fix uninversioning of (single valued) PointFields & clean up some related code

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-10472.
-
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.6

> Fix uninversioning of (single valued) PointFields & clean up some related code
> --
>
> Key: SOLR-10472
> URL: https://issues.apache.org/jira/browse/SOLR-10472
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10472.patch, SOLR-10472.patch, SOLR-10472.patch
>
>
> In getting caught up with the new PointsField work in SOLR-8396 & SOLR-9987 I 
> realized:
> * There's some inconsistencies/contridictions in how the new field types 
> implement {{FieldType.getUninversionType}} vs some of the error handling 
> added to methods like {{SchemaField.checkSortability}}.
> * as part of SOLR-9987, {{SORTED_foo}} constants were added to 
> {{UninvertingReader}} and used in the {{getUninversionType}} methods for 
> PointFields -- even though those constants are useless (because 
> {{UninvertingReader}} doesn't support uninverting multivalued points: 
> SOLR-9202)
> * the changes made to methods like {{SchemaField.checkSortability}} to 
> explicitly check {{isPointsField}} should have never been needed if those 
> methods were paying attention to {{getUninversionType}} -- but those types of 
> checks weren't added when {{getUninversionType}} was introduced (the existing 
> checks pre-date the DocValues API, back where any single-valued indexed field 
> was implicitily "uninvertable")
> * If all of the above is corrected, the only thing preventing 
> {{UninvertedReader}} from working properly with Solr's new PointField types 
> (in the single valued case) is a trivial bug in {{IndexSchema}} (being 
> presumptutious about what is uninvertable)
> I'm opening this issue to track fixing all of this, such that the end result 
> will be:
> * single valued PointFields will be uninvertable (ie: sortable even if they 
> don't have docvalues)
> * error handling code will be simplified
> * unused/unsupported/misleading constants in {{UninvertingReader}} will be 
> removed.



--
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-10472) Fix uninversioning of (single valued) PointFields & clean up some related code

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10472:


Commit dedb0255947ed936e001b244ff1859075398dc40 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dedb025 ]

SOLR-10472: Fixed uninversion (aka: FieldCache) bugs with the numeric 
PointField classes, and CurrencyField

(cherry picked from commit 10772121eee97023aed415751e49a06d116b26ad)

Conflicts in test due to slightly diff internal DocValues APIs on master vs 6x
solr/core/src/test/org/apache/solr/schema/TestPointFields.java


> Fix uninversioning of (single valued) PointFields & clean up some related code
> --
>
> Key: SOLR-10472
> URL: https://issues.apache.org/jira/browse/SOLR-10472
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-10472.patch, SOLR-10472.patch, SOLR-10472.patch
>
>
> In getting caught up with the new PointsField work in SOLR-8396 & SOLR-9987 I 
> realized:
> * There's some inconsistencies/contridictions in how the new field types 
> implement {{FieldType.getUninversionType}} vs some of the error handling 
> added to methods like {{SchemaField.checkSortability}}.
> * as part of SOLR-9987, {{SORTED_foo}} constants were added to 
> {{UninvertingReader}} and used in the {{getUninversionType}} methods for 
> PointFields -- even though those constants are useless (because 
> {{UninvertingReader}} doesn't support uninverting multivalued points: 
> SOLR-9202)
> * the changes made to methods like {{SchemaField.checkSortability}} to 
> explicitly check {{isPointsField}} should have never been needed if those 
> methods were paying attention to {{getUninversionType}} -- but those types of 
> checks weren't added when {{getUninversionType}} was introduced (the existing 
> checks pre-date the DocValues API, back where any single-valued indexed field 
> was implicitily "uninvertable")
> * If all of the above is corrected, the only thing preventing 
> {{UninvertedReader}} from working properly with Solr's new PointField types 
> (in the single valued case) is a trivial bug in {{IndexSchema}} (being 
> presumptutious about what is uninvertable)
> I'm opening this issue to track fixing all of this, such that the end result 
> will be:
> * single valued PointFields will be uninvertable (ie: sortable even if they 
> don't have docvalues)
> * error handling code will be simplified
> * unused/unsupported/misleading constants in {{UninvertingReader}} will be 
> removed.



--
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-7544) UnifiedHighlighter should allow extension for custom query types

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7544:


Github user michaelbraun closed the pull request at:

https://github.com/apache/lucene-solr/pull/111


> UnifiedHighlighter should allow extension for custom query types
> 
>
> Key: LUCENE-7544
> URL: https://issues.apache.org/jira/browse/LUCENE-7544
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Michael Braun
>Assignee: David Smiley
> Fix For: 6.4
>
> Attachments: LUCENE-7544.patch
>
>
> In our use case, we have custom query types (both SpanQuery and 
> non-SpanQuery) which are not provided by Lucene. UnifiedHighlighter needs 
> extension points to handle some custom query types in order for highlighting 
> to be accurate. This issue represents adding two extension point methods to 
> support custom query types.



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

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

[GitHub] lucene-solr pull request #111: LUCENE-7544 - add UnifiedHighlighter extensio...

[michaelbraun]

Github user michaelbraun closed the pull request at:

https://github.com/apache/lucene-solr/pull/111


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

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

[jira] [Commented] (LUCENE-7786) TermInSetQuery should include a getter for field

[Michael Braun (JIRA)]

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

Michael Braun commented on LUCENE-7786:
---

Added a really simple getter - anything else that needs to be added for this?

> TermInSetQuery should include a getter for field
> 
>
> Key: LUCENE-7786
> URL: https://issues.apache.org/jira/browse/LUCENE-7786
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (7.0), 6.5
>Reporter: Michael Braun
>Priority: Trivial
>
> Per LUCENE-7637, TermInSetQuery is restricted to a single field. However, 
> there is no getter for the field. A public getter should be added to expose 
> the field name.



--
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-7786) TermInSetQuery should include a getter for field

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7786:


GitHub user michaelbraun opened a pull request:

https://github.com/apache/lucene-solr/pull/192

LUCENE-7786 - add getter for field to TermInSetQuery



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/michaelbraun/lucene-solr LUCENE-7786

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/192.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #192


commit 0dfd870ba75380b6b1611953b71cf9b63da8cec7
Author: Michael Braun 
Date:   2017-04-18T21:05:29Z

LUCENE-7786 - add getter for field to TermInSetQuery




> TermInSetQuery should include a getter for field
> 
>
> Key: LUCENE-7786
> URL: https://issues.apache.org/jira/browse/LUCENE-7786
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (7.0), 6.5
>Reporter: Michael Braun
>Priority: Trivial
>
> Per LUCENE-7637, TermInSetQuery is restricted to a single field. However, 
> there is no getter for the field. A public getter should be added to expose 
> the field name.



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

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

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

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10439:
-

BTW my patch didn't include an update to the {{TestFieldResource.java}} but can 
now obviously be observed in git.

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



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

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

[GitHub] lucene-solr pull request #192: LUCENE-7786 - add getter for field to TermInS...

[michaelbraun]

GitHub user michaelbraun opened a pull request:

https://github.com/apache/lucene-solr/pull/192

LUCENE-7786 - add getter for field to TermInSetQuery



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/michaelbraun/lucene-solr LUCENE-7786

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/192.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #192


commit 0dfd870ba75380b6b1611953b71cf9b63da8cec7
Author: Michael Braun 
Date:   2017-04-18T21:05:29Z

LUCENE-7786 - add getter for field to TermInSetQuery




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

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

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

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-10439.
-
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.6
   6.5.1

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



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

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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10439:


Commit f363cb52c7561a57cc3e19e411dcde87bb8c388d in lucene-solr's branch 
refs/heads/branch_6_5 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f363cb5 ]

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

(cherry picked from commit a4e5dba)


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



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

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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10439:


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

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

(cherry picked from commit 8347169)


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



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

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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10439:


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

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


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



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

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

[jira] [Commented] (LUCENE-7786) TermInSetQuery should include a getter for field

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7786:


+1

> TermInSetQuery should include a getter for field
> 
>
> Key: LUCENE-7786
> URL: https://issues.apache.org/jira/browse/LUCENE-7786
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (7.0), 6.5
>Reporter: Michael Braun
>Priority: Trivial
>
> Per LUCENE-7637, TermInSetQuery is restricted to a single field. However, 
> there is no getter for the field. A public getter should be added to expose 
> the field name.



--
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-7786) TermInSetQuery should include a getter for field

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7786:


+1

> TermInSetQuery should include a getter for field
> 
>
> Key: LUCENE-7786
> URL: https://issues.apache.org/jira/browse/LUCENE-7786
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (7.0), 6.5
>Reporter: Michael Braun
>Priority: Trivial
>
> Per LUCENE-7637, TermInSetQuery is restricted to a single field. However, 
> there is no getter for the field. A public getter should be added to expose 
> the field name.



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

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

[jira] [Closed] (SOLR-3390) Highlighting issue with multi-word synonyms causes to highlight the wrong terms

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-3390.

Resolution: Not A Problem
  Assignee: Steve Rowe

This no longer appears to be a problem.

Please reopen if modern Solr exhibits this.

> Highlighting issue with multi-word synonyms causes to highlight the wrong 
> terms
> ---
>
> Key: SOLR-3390
> URL: https://issues.apache.org/jira/browse/SOLR-3390
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter, query parsers
>Affects Versions: 3.6
> Environment: Windows 7. (Development machine, not the server) 
>Reporter: Rahul Babulal
>Assignee: Steve Rowe
>  Labels: highlighter, multi-word, solr, synonyms
>
> I am using solr 3.6 and when I have multi-words synonyms the highlighting 
> results have the wrong word highlighted. 
> If I have the below entry in the synonyms file:
> dns, domain name system 
> If I index something like: "A sample dns entry explaining the details".
> Searching for "name" (without quotes) in the highlight results/snippets I get 
> :  "A sample dns entry explaining the details". (The token "entry" 
> overlaps with the token "name" in the analysis.jsp)
> Searching for "system" (without quotes) in the highlight results/snippets I 
> get :  "A sample dns entry explaining the details". (The token 
> "explaining" overlaps with the token "system" in the analysis.jsp)
> Here is my schema field Type:
>  positionIncrementGap="100">
>   
> 
> 
>  ignoreCase="true" expand="true"/>
>  words="stopwords.txt" enablePositionIncrements="true" />
> 
> 
>   
>   
> 
>  ignoreCase="true" expand="false"/>
>  words="stopwords.txt" enablePositionIncrements="true" />
>   
> 
>   
> 



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

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

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Michael McCandless]

OK backported!

Mike McCandless

http://blog.mikemccandless.com

On Tue, Apr 18, 2017 at 4:41 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Thanks for the suggestion David; I will backport LUCENE- shortly.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Tue, Apr 18, 2017 at 2:55 PM, David Smiley 
> wrote:
>
>> Hmm; there are a lot of Solr bugs fixed in 6.6 but not yet 6.5.1... I
>> wonder why others aren't back-porting their fixed bugs?
>> Lucene has one: LUCENE-  Mike should it be ported to 6.5.1?
>>
>> On Tue, Apr 18, 2017 at 1:28 PM Joel Bernstein 
>> wrote:
>>
>>> Sure
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> On Tue, Apr 18, 2017 at 1:20 PM, David Smiley 
>>> wrote:
>>>
 I've been sitting on these bug fixes (see below) in case there will be
 another RC and now it looks like there will be one.  Joel, shall I commit
 them to the release branch?


 On Mon, Apr 10, 2017 at 2:47 PM David Smiley 
 wrote:

> +1 SUCCESS! [0:48:18.176212]
>
> If there is a respin for any reason, I'd suggest including LUCENE-7769
> (UH boost query) and SOLR-10439 ('large' and SchemaField)
>
> ~ David
>
> On Mon, Apr 10, 2017 at 2:07 PM Adrien Grand 
> wrote:
>
> +1 SUCCESS! [1:46:31.647123]
>
> Le lun. 10 avr. 2017 à 05:01, Joel Bernstein  a
> écrit :
>
> Please vote for release candidate 1 for Lucene/Solr 6.5.1The artifacts 
> can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>
> You can run the smoke tester directly with this command:python3 -u 
> dev-tools/scripts/smokeTestRelease.py 
> \https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>
> Here's my +1
>
> SUCCESS! [0:40:54.049621]
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
 --
 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
 http://www.solrenterprisesearchserver.com

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

[jira] [Updated] (LUCENE-7777) ByteBlockPool.readBytes incorrectly throws AIOOBE if length > 32768

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-:
---
Fix Version/s: 6.5.1

> ByteBlockPool.readBytes incorrectly throws AIOOBE if length > 32768
> ---
>
> Key: LUCENE-
> URL: https://issues.apache.org/jira/browse/LUCENE-
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.6, 6.5.1
>
> Attachments: LUCENE-.patch
>
>
> I'm using Lucene's OfflineSorter to sort a large data set, and some of the 
> items in the set are > 32 KB in length, which tickled a bug in its 
> {{readBytes}}.



--
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-7777) ByteBlockPool.readBytes incorrectly throws AIOOBE if length > 32768

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-:
-

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

LUCENE-: fix AIOOBE from ByteBlockPool.readBytes when byte block exceeds 32 
KB


> ByteBlockPool.readBytes incorrectly throws AIOOBE if length > 32768
> ---
>
> Key: LUCENE-
> URL: https://issues.apache.org/jira/browse/LUCENE-
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.6
>
> Attachments: LUCENE-.patch
>
>
> I'm using Lucene's OfflineSorter to sort a large data set, and some of the 
> items in the set are > 32 KB in length, which tickled a bug in its 
> {{readBytes}}.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum resolved SOLR-10420.
---
Resolution: Fixed

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 5.6, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10420:


Commit 89beee8d61346d50dbbf02f0cc9cfc5032e46eee in lucene-solr's branch 
refs/heads/branch_5_5 from [~dragonsinth]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=89beee8 ]

SOLR-10420: fix watcher leak in DistributedQueue


> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 5.6, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



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

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

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Michael McCandless]

Thanks for the suggestion David; I will backport LUCENE- shortly.

Mike McCandless

http://blog.mikemccandless.com

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

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

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

 ~ David

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

 +1 SUCCESS! [1:46:31.647123]

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

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

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

 You can run the smoke tester directly with this command:python3 -u 
 dev-tools/scripts/smokeTestRelease.py 
 \https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539

 Here's my +1

 SUCCESS! [0:40:54.049621]

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

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

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

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

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-10394:
---
Attachment: SOLR-10394-part2.patch

Attaching 'part 2' patch which is essentially non-public sortWithinGroup to 
withinGroupSort renames, for clarity and to reduce the complexity of the 
SOLR-6203 changes.

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



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

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

[jira] [Commented] (SOLR-8668) Remove support for (in favour of )

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8668:
---

Made a start on this with a first commit on 
https://github.com/apache/lucene-solr/tree/jira/solr-8668 - not the most 
exciting of changes admittedly but it would be good for  to go 
away from Solr 7.0 onwards in favour of  given that 
SOLR-8621 deprecated  from Solr 5.5 onwards.

Collaboration and/or code reviews welcome, e.g. do we need to throw an 
exception if anyone still configures  or is it fair to silently 
ignore it? solr/CHANGES.txt will obviously need to mention about  
support being removed from 7.0 onwards.

> Remove support for  (in favour of )
> 
>
> Key: SOLR-8668
> URL: https://issues.apache.org/jira/browse/SOLR-8668
> Project: Solr
>  Issue Type: Improvement
>Reporter: Shai Erera
>Priority: Blocker
> Fix For: master (7.0)
>
>
> Following SOLR-8621, we should remove support for {{}} (and 
> related {{}} and {{}}) in trunk/6x.



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

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([A7A02C4346DA3099:5EEDBFEC7AAF7D13]: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.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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 

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

[jitka18]

Github user jitka18 commented on the issue:

https://github.com/apache/lucene-solr/pull/189
  
Hi, Christine.  Sounds good---I hope to have time this evening to catch up
with the collaboration business.  Thanks for fixing the indentation in your
most recent commit on your fork.  I suppose the commit before that is a
matter of taste---it seemed strange to me to feed the constructor values
that we know might not be the final ones and then to turn around
immediately and adjust them, but there is less duplication the way you have
it.  Your way is fine with me.  We could probably do some tweaks here and
there and come up with something even cleaner but I'd rather stay focused
for now.
Thanks,
Judith

On Tue, Apr 18, 2017 at 11:35 AM, Christine Poerschke <
notificati...@github.com> wrote:

> Hi Judith - I've just gone to https://github.com/cpoerschke/
> lucene-solr/settings/collaboration and invited you as a collaborator for
> my lucene-solr fork here on github. If you'd be happy to do the same then
> we can send each other pull requests. The two top commits on
> https://github.com/cpoerschke/lucene-solr/tree/jira/solr-6203 as one PR
> for example, easier to send a PR rather than comment in the code? Thanks. 
-
> Christine
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 

> .
>



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

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

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Scott Blum]

Commit e3beb61a72efbce37710ce3cc48b24093070d052 in lucene-solr's branch
refs/heads/branch_6_5 from Scott Blum

[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e3beb61 ]

SOLR-10420 : fix watcher
leak in DistributedQueue

On Tue, Apr 18, 2017 at 3:50 PM, David Smiley 
wrote:

> You can fix whatever bug fix you find on a bug-fix release.
>
> On Tue, Apr 18, 2017 at 3:28 PM Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
>> I've held back from porting to 6.5.1 on the assumption that 6.5.1 would
>> be mostly to fix bugs introduced in 6.5.0 but not necessarily bugs that
>> existed before then, unless the fixes are small and/or the bug serious e.g.
>> security issues.
>>
>> Not quite sure how that assumption came about.
>>
>> http://lucene.apache.org/solr/community.html#about-versions mentions 6.x
>> vs. 5.5.x but is silent on 6.x vs. 6.x.y difference.
>>
>> Christine
>>
>> From: dev@lucene.apache.org At: 04/18/17 19:55:56
>> To: dev@lucene.apache.org
>> Subject: Re: [VOTE] Release Lucene/Solr 6.5.1 RC1
>>
>> Hmm; there are a lot of Solr bugs fixed in 6.6 but not yet 6.5.1... I
>> wonder why others aren't back-porting their fixed bugs?
>> Lucene has one: LUCENE-  Mike should it be ported to 6.5.1?
>>
>> On Tue, Apr 18, 2017 at 1:28 PM Joel Bernstein 
>> wrote:
>>
>>> Sure
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> On Tue, Apr 18, 2017 at 1:20 PM, David Smiley 
>>> wrote:
>>>
 I've been sitting on these bug fixes (see below) in case there will be
 another RC and now it looks like there will be one.  Joel, shall I commit
 them to the release branch?


 On Mon, Apr 10, 2017 at 2:47 PM David Smiley 
 wrote:

> +1 SUCCESS! [0:48:18.176212]
>
> If there is a respin for any reason, I'd suggest including LUCENE-7769
> (UH boost query) and SOLR-10439 ('large' and SchemaField)
>
> ~ David
>
> On Mon, Apr 10, 2017 at 2:07 PM Adrien Grand 
> wrote:
>
> +1 SUCCESS! [1:46:31.647123]
>
> Le lun. 10 avr. 2017 à 05:01, Joel Bernstein  a
> écrit :
>
> Please vote for release candidate 1 for Lucene/Solr 6.5.1The artifacts 
> can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>
> You can run the smoke tester directly with this command:python3 -u 
> dev-tools/scripts/smokeTestRelease.py 
> \https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>
> Here's my +1
>
> SUCCESS! [0:40:54.049621]
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>
 --
 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
 solrenterprisesearchserver.com

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

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10420:


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

SOLR-10420: fix watcher leak in DistributedQueue


> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 5.6, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



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

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

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[David Smiley]

You can fix whatever bug fix you find on a bug-fix release.

On Tue, Apr 18, 2017 at 3:28 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> I've held back from porting to 6.5.1 on the assumption that 6.5.1 would be
> mostly to fix bugs introduced in 6.5.0 but not necessarily bugs that
> existed before then, unless the fixes are small and/or the bug serious e.g.
> security issues.
>
> Not quite sure how that assumption came about.
>
> http://lucene.apache.org/solr/community.html#about-versions mentions 6.x
> vs. 5.5.x but is silent on 6.x vs. 6.x.y difference.
>
> Christine
>
> From: dev@lucene.apache.org At: 04/18/17 19:55:56
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Release Lucene/Solr 6.5.1 RC1
>
> Hmm; there are a lot of Solr bugs fixed in 6.6 but not yet 6.5.1... I
> wonder why others aren't back-porting their fixed bugs?
> Lucene has one: LUCENE-  Mike should it be ported to 6.5.1?
>
> On Tue, Apr 18, 2017 at 1:28 PM Joel Bernstein  wrote:
>
>> Sure
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Tue, Apr 18, 2017 at 1:20 PM, David Smiley 
>> wrote:
>>
>>> I've been sitting on these bug fixes (see below) in case there will be
>>> another RC and now it looks like there will be one.  Joel, shall I commit
>>> them to the release branch?
>>>
>>>
>>> On Mon, Apr 10, 2017 at 2:47 PM David Smiley 
>>> wrote:
>>>
 +1 SUCCESS! [0:48:18.176212]

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

 ~ David

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

 +1 SUCCESS! [1:46:31.647123]

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

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

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

 You can run the smoke tester directly with this command:python3 -u 
 dev-tools/scripts/smokeTestRelease.py 
 \https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539

 Here's my +1

 SUCCESS! [0:40:54.049621]

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

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

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

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10420:


Commit 42d08dd28c6609a2c70a691e6a88725c9aa31377 in lucene-solr's branch 
refs/heads/branch_5x from [~dragonsinth]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=42d08dd ]

SOLR-10420: fix watcher leak in DistributedQueue


> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 5.6, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10420:


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

SOLR-10420: fix watcher leak in DistributedQueue


> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 5.6, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([24ED6A41CE572906:EB730F7841A64159]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
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 11898 lines...]
   

[jira] [Updated] (SOLR-10516) Add eval() Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10516:
--
Attachment: SOLR-10516.patch

First implementation without tests.

> Add eval() Streaming Expression
> ---
>
> Key: SOLR-10516
> URL: https://issues.apache.org/jira/browse/SOLR-10516
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10516.patch
>
>
> The eval() Streaming Expression reads a single tuple from an underlying 
> stream and looks in the expr_s field for an expression to compile and run. 
> eval emits the tuples from the expression that it compiles. 
> This allows streaming expressions to write streaming expressions and have 
> them evaluated.
> Syntax:
> {code}
> eval(expr)
> {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

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-10420:
---

Got it.  I do think it would be a mistake.  In that case, after I've committed 
to 5x and 6x, I'll also commit to 6_5 and 5_5.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 5.6, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-10420:
--
Fix Version/s: (was: 6.4.3)

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 5.6, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10516) Add eval() Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10516:
--
Description: 
The eval() Streaming Expression reads a single tuple from an underlying stream 
and looks in the expr_s field for an expression to compile and run. eval emits 
the tuples from the expression that it compiles. 

This allows streaming expressions to write streaming expressions and have them 
evaluated.

Syntax:
{code}
eval(expr)
{code}

  was:
The eval() Streaming Expression reads a single tuple from an underlying stream 
and looks in the expr_s field for an expression to compile and run. eval emits 
the tuples from expression that it compiles. 

This allows streaming expressions to write streaming expressions and have them 
evaluated in the same.


> Add eval() Streaming Expression
> ---
>
> Key: SOLR-10516
> URL: https://issues.apache.org/jira/browse/SOLR-10516
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The eval() Streaming Expression reads a single tuple from an underlying 
> stream and looks in the expr_s field for an expression to compile and run. 
> eval emits the tuples from the expression that it compiles. 
> This allows streaming expressions to write streaming expressions and have 
> them evaluated.
> Syntax:
> {code}
> eval(expr)
> {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

[jira] [Updated] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-10420:
--
Fix Version/s: 5.6

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 5.6, 6.4.3, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10516) Add eval() Streaming Expression

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10516:
-

 Summary: Add eval() Streaming Expression
 Key: SOLR-10516
 URL: https://issues.apache.org/jira/browse/SOLR-10516
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The eval() Streaming Expression reads a single tuple from an underlying stream 
and looks in the expr_s field for an expression to compile and run. eval emits 
the tuples from expression that it compiles. 

This allows streaming expressions to write streaming expressions and have them 
evaluated in the same.



--
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: Resources/pointers on hacking on solr

[Ishan Chattopadhyaya]

https://wiki.apache.org/solr/HowToContribute

On Wed, Apr 19, 2017 at 12:41 AM, Dorian Hoxha 
wrote:

> Hey friends,
>
> I'll be having some free time in the next 2 weeks and would like to get up
> to speed on hacking on solr. I've done very little java on university so
> I'd like to get on speed on java too together with that.
>
> So if you can give me some high level pointers if possible on:::
>
> 1. getting up to speed on java
> 2. environment (like i have idea ide, ubuntu 16.04, java 1.8)
> 3. I'd like to embed solr but only to make distributed requests and not
> store data. So, my java-webapp calls a solr-function in the same jvm, which
> doesn't store data itself but has the state of all other nodes and it can
> do the merging of results. This way I make 1 less http-request for each
> distributed-search. Something like on elasticsearch with search-only-nodes
> but also to include it in my java webapp.
> 4. A way to create a module to subclass router.compositeid to create my
> own logic on routing documents *(most important). *
> 5. A way to create a module (or something else?) so I can change the
> sorting of documents to not limit() docs if the last ones have the same
> sort-value (so doing this on each shard, and also on the merging). Meaning
> if we have limit(10), but docs 10-20 have the same sort-value, we return 20
> (as long as 20 < max_limit(), which does the same cut as limit() currently
> does). I think currently it uses a min-heap, so maybe a similar data
> structure that also keeps duplicates at the end.
> 6. How to test all this stuff ? Or just create test cases and make sure
> they keep working ?
>
> Hope I'm not asking too much.
>
> Regards,
> Dorian
>

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Christine Poerschke (BLOOMBERG/ LONDON)]

I've held back from porting to 6.5.1 on the assumption that 6.5.1 would be 
mostly to fix bugs introduced in 6.5.0 but not necessarily bugs that existed 
before then, unless the fixes are small and/or the bug serious e.g. security 
issues.

Not quite sure how that assumption came about.

http://lucene.apache.org/solr/community.html#about-versions mentions 6.x vs. 
5.5.x but is silent on 6.x vs. 6.x.y difference.

Christine

From: dev@lucene.apache.org At: 04/18/17 19:55:56
To: dev@lucene.apache.org
Subject: Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

Hmm; there are a lot of Solr bugs fixed in 6.6 but not yet 6.5.1... I wonder 
why others aren't back-porting their fixed bugs?
Lucene has one: LUCENE-  Mike should it be ported to 6.5.1?
On Tue, Apr 18, 2017 at 1:28 PM Joel Bernstein  wrote:

Sure

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

On Tue, Apr 18, 2017 at 1:20 PM, David Smiley  wrote:

I've been sitting on these bug fixes (see below) in case there will be another 
RC and now it looks like there will be one.  Joel, shall I commit them to the 
release branch?


On Mon, Apr 10, 2017 at 2:47 PM David Smiley  wrote:

+1 SUCCESS! [0:48:18.176212]

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

~ David

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

+1 SUCCESS! [1:46:31.647123]

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

Please vote for release candidate 1 for Lucene/Solr 6.5.1

The artifacts can be downloaded 
from:https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539

You can run the smoke tester directly with this command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
Here's my +1SUCCESS! [0:40:54.049621]
Joel Bernstein
http://joelsolr.blogspot.com/


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


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

[jira] [Updated] (SOLR-10485) Add calc() Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10485:
--
Description: 
The calc() function can be used inside of the select function to execute 
Evaluators:

{code}
select(calc(), add(1, 1) as result)
{code}

The example above returns a single Tuple with the result of add(1, 1) in the 
*result* field. This allows Streaming Expressions to perform calculations 
directly without requiring an underlying stream.


  was:
The eval() function can be used inside of the select function to execute 
Evaluators:

{code}
select(eval(), add(1, 1) as result)
{code}

The example above returns a single Tuple with the result of add(1, 1) in the 
*result* field. This allows Streaming Expressions to perform calculations 
directly without requiring an underlying stream.



> Add calc() Streaming Expression
> ---
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The calc() function can be used inside of the select function to execute 
> Evaluators:
> {code}
> select(calc(), add(1, 1) as result)
> {code}
> The example above returns a single Tuple with the result of add(1, 1) in the 
> *result* field. This allows Streaming Expressions to perform calculations 
> directly without requiring an underlying stream.



--
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-10485) Add calc() Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10485:
--
Summary: Add calc() Streaming Expression  (was: Add eval() Streaming 
Expression to execute Evaluators)

> Add calc() Streaming Expression
> ---
>
> Key: SOLR-10485
> URL: https://issues.apache.org/jira/browse/SOLR-10485
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10485.patch
>
>
> The eval() function can be used inside of the select function to execute 
> Evaluators:
> {code}
> select(eval(), add(1, 1) as result)
> {code}
> The example above returns a single Tuple with the result of add(1, 1) in the 
> *result* field. This allows Streaming Expressions to perform calculations 
> directly without requiring an underlying stream.



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

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

[jira] [Comment Edited] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10420 at 4/18/17 7:23 PM:


bq. So my plan is to commit this to master, branch_6x, and branch_5x, and let 
the release managers pull it into the actual release branches. SG?

I think at a minimum you should also commit to branch_6_5, since it's 
definitely going to be released, and you'll be better equipped to handle 
conflicts if there are any.

I noticed you set fixVersion to releases on branches you won't be committing 
to: 6.4.3, 5.5.5.  I don't think you should do that.  If you're going to commit 
to branch_5x, then the fixVersion would be 5.6, since that's the next release 
on that branch.  Unless you commit to branch_6_4, you shouldn't include 6.4.3 
as a fixVersion.

More generally, if you think it's essential that any X.Y.Z release includes 
this fix, i.e. that it would be a mistake to release without it, then you 
should commit to the branch from which that release will be made.  Otherwise 
you and others may/will forget to backport when such a release materializes.


was (Author: steve_rowe):
bq. So my plan is to commit this to master, branch_6x, and branch_5x, and let 
the release managers pull it into the actual release branches. SG?

I think at a minimum you should also commit to branch_6_5, since it's a known 
release, since you'll be better equipped to handle conflicts if there are any.

I noticed you set fixVersion to releases on branches you won't be committing 
to: 6.4.3, 5.5.5.  I don't think you should do that.  If you're going to commit 
to branch_5x, then the fixVersion would be 5.6, since that's the next release 
on that branch.  Unless you commit to branch_6_4, you shouldn't include 6.4.3 
as a fixVersion.

More generally, if you think it's essential that any X.Y.Z release includes 
this fix, i.e. that it would be a mistake to release without it, then you 
should commit to the branch from which that release will be made.  Otherwise 
you and others may/will forget to backport when such a release materializes.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 6.4.3, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



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

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

[jira] [Comment Edited] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10420 at 4/18/17 7:23 PM:


bq. So my plan is to commit this to master, branch_6x, and branch_5x, and let 
the release managers pull it into the actual release branches. SG?

I think at a minimum you should also commit to branch_6_5, since it's a known 
release, since you'll be better equipped to handle conflicts if there are any.

I noticed you set fixVersion to releases on branches you won't be committing 
to: 6.4.3, 5.5.5.  I don't think you should do that.  If you're going to commit 
to branch_5x, then the fixVersion would be 5.6, since that's the next release 
on that branch.  Unless you commit to branch_6_4, you shouldn't include 6.4.3 
as a fixVersion.

More generally, if you think it's essential that any X.Y.Z release includes 
this fix, i.e. that it would be a mistake to release without it, then you 
should commit to the branch from which that release will be made.  Otherwise 
you and others may/will forget to backport when such a release materializes.


was (Author: steve_rowe):
bq.

I think at a minimum you should also commit to branch_6_5, since it's a known 
release, since you'll be better equipped to handle conflicts if there are any.

I noticed you set fixVersion to releases on branches you won't be committing 
to: 6.4.3, 5.5.5.  I don't think you should do that.  If you're going to commit 
to branch_5x, then the fixVersion would be 5.6, since that's the next release 
on that branch.  Unless you commit to branch_6_4, you shouldn't include 6.4.3 
as a fixVersion.

More generally, if you think it's essential that any X.Y.Z release includes 
this fix, i.e. that it would be a mistake to release without it, then you 
should commit to the branch from which that release will be made.  Otherwise 
you and others may/will forget to backport when such a release materializes.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 6.4.3, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10420:
-

I think you should do master, branch_6x and branch_6_5. branch_5x is optional.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 6.4.3, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10420:
---

bq.

I think at a minimum you should also commit to branch_6_5, since it's a known 
release, since you'll be better equipped to handle conflicts if there are any.

I noticed you set fixVersion to releases on branches you won't be committing 
to: 6.4.3, 5.5.5.  I don't think you should do that.  If you're going to commit 
to branch_5x, then the fixVersion would be 5.6, since that's the next release 
on that branch.  Unless you commit to branch_6_4, you shouldn't include 6.4.3 
as a fixVersion.

More generally, if you think it's essential that any X.Y.Z release includes 
this fix, i.e. that it would be a mistake to release without it, then you 
should commit to the branch from which that release will be made.  Otherwise 
you and others may/will forget to backport when such a release materializes.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 6.4.3, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-7746) precommit to ignore less and (potentially) error more

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated LUCENE-7746:

Fix Version/s: (was: 6.x)
   6.6

> precommit to ignore less and (potentially) error more
> -
>
> Key: LUCENE-7746
> URL: https://issues.apache.org/jira/browse/LUCENE-7746
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (7.0), 6.6
>
> Attachments: LUCENE-7746.patch
>
>




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

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

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-10420:
---

So my plan is to commit this to master, branch_6x, and branch_5x, and let the 
release managers pull it into the actual release branches.  SG?

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 6.4.3, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



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

Resources/pointers on hacking on solr

[Dorian Hoxha]

Hey friends,

I'll be having some free time in the next 2 weeks and would like to get up
to speed on hacking on solr. I've done very little java on university so
I'd like to get on speed on java too together with that.

So if you can give me some high level pointers if possible on:::

1. getting up to speed on java
2. environment (like i have idea ide, ubuntu 16.04, java 1.8)
3. I'd like to embed solr but only to make distributed requests and not
store data. So, my java-webapp calls a solr-function in the same jvm, which
doesn't store data itself but has the state of all other nodes and it can
do the merging of results. This way I make 1 less http-request for each
distributed-search. Something like on elasticsearch with search-only-nodes
but also to include it in my java webapp.
4. A way to create a module to subclass router.compositeid to create my own
logic on routing documents *(most important). *
5. A way to create a module (or something else?) so I can change the
sorting of documents to not limit() docs if the last ones have the same
sort-value (so doing this on each shard, and also on the merging). Meaning
if we have limit(10), but docs 10-20 have the same sort-value, we return 20
(as long as 20 < max_limit(), which does the same cut as limit() currently
does). I think currently it uses a min-heap, so maybe a similar data
structure that also keeps duplicates at the end.
6. How to test all this stuff ? Or just create test cases and make sure
they keep working ?

Hope I'm not asking too much.

Regards,
Dorian

[jira] [Commented] (SOLR-10505) Support terms' statistics for multiple fields in TermsComponent

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-10505:
---

All tests pass, if there are no objections, I'd like to commit this.

> Support terms' statistics for multiple fields in TermsComponent
> ---
>
> Key: SOLR-10505
> URL: https://issues.apache.org/jira/browse/SOLR-10505
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shai Erera
>Assignee: Shai Erera
> Attachments: SOLR-10505.patch
>
>
> Currently if you specify multiple {{terms.fl}} parameters on the request, 
> while requesting terms' statistics, you get them for the first requested 
> field (because the code only uses {{fields[0]}}). There's no reason why not 
> to return the stats for the terms in all specified fields. It's a rather 
> simple change, and I will post a patch shortly.



--
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-10472) Fix uninversioning of (single valued) PointFields & clean up some related code

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10472:
-

on master, planning to backport to 6x this afternoon/tomorrow.

> Fix uninversioning of (single valued) PointFields & clean up some related code
> --
>
> Key: SOLR-10472
> URL: https://issues.apache.org/jira/browse/SOLR-10472
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10472.patch, SOLR-10472.patch, SOLR-10472.patch
>
>
> In getting caught up with the new PointsField work in SOLR-8396 & SOLR-9987 I 
> realized:
> * There's some inconsistencies/contridictions in how the new field types 
> implement {{FieldType.getUninversionType}} vs some of the error handling 
> added to methods like {{SchemaField.checkSortability}}.
> * as part of SOLR-9987, {{SORTED_foo}} constants were added to 
> {{UninvertingReader}} and used in the {{getUninversionType}} methods for 
> PointFields -- even though those constants are useless (because 
> {{UninvertingReader}} doesn't support uninverting multivalued points: 
> SOLR-9202)
> * the changes made to methods like {{SchemaField.checkSortability}} to 
> explicitly check {{isPointsField}} should have never been needed if those 
> methods were paying attention to {{getUninversionType}} -- but those types of 
> checks weren't added when {{getUninversionType}} was introduced (the existing 
> checks pre-date the DocValues API, back where any single-valued indexed field 
> was implicitily "uninvertable")
> * If all of the above is corrected, the only thing preventing 
> {{UninvertedReader}} from working properly with Solr's new PointField types 
> (in the single valued case) is a trivial bug in {{IndexSchema}} (being 
> presumptutious about what is uninvertable)
> I'm opening this issue to track fixing all of this, such that the end result 
> will be:
> * single valued PointFields will be uninvertable (ie: sortable even if they 
> don't have docvalues)
> * error handling code will be simplified
> * unused/unsupported/misleading constants in {{UninvertingReader}} will be 
> removed.



--
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] [Assigned] (SOLR-10472) Fix uninversioning of (single valued) PointFields & clean up some related code

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-10472:
---

Assignee: Hoss Man

> Fix uninversioning of (single valued) PointFields & clean up some related code
> --
>
> Key: SOLR-10472
> URL: https://issues.apache.org/jira/browse/SOLR-10472
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-10472.patch, SOLR-10472.patch, SOLR-10472.patch
>
>
> In getting caught up with the new PointsField work in SOLR-8396 & SOLR-9987 I 
> realized:
> * There's some inconsistencies/contridictions in how the new field types 
> implement {{FieldType.getUninversionType}} vs some of the error handling 
> added to methods like {{SchemaField.checkSortability}}.
> * as part of SOLR-9987, {{SORTED_foo}} constants were added to 
> {{UninvertingReader}} and used in the {{getUninversionType}} methods for 
> PointFields -- even though those constants are useless (because 
> {{UninvertingReader}} doesn't support uninverting multivalued points: 
> SOLR-9202)
> * the changes made to methods like {{SchemaField.checkSortability}} to 
> explicitly check {{isPointsField}} should have never been needed if those 
> methods were paying attention to {{getUninversionType}} -- but those types of 
> checks weren't added when {{getUninversionType}} was introduced (the existing 
> checks pre-date the DocValues API, back where any single-valued indexed field 
> was implicitily "uninvertable")
> * If all of the above is corrected, the only thing preventing 
> {{UninvertedReader}} from working properly with Solr's new PointField types 
> (in the single valued case) is a trivial bug in {{IndexSchema}} (being 
> presumptutious about what is uninvertable)
> I'm opening this issue to track fixing all of this, such that the end result 
> will be:
> * single valued PointFields will be uninvertable (ie: sortable even if they 
> don't have docvalues)
> * error handling code will be simplified
> * unused/unsupported/misleading constants in {{UninvertingReader}} will be 
> removed.



--
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-10472) Fix uninversioning of (single valued) PointFields & clean up some related code

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10472:


Commit 10772121eee97023aed415751e49a06d116b26ad in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1077212 ]

SOLR-10472: Fixed uninversion (aka: FieldCache) bugs with the numeric 
PointField classes, and CurrencyField


> Fix uninversioning of (single valued) PointFields & clean up some related code
> --
>
> Key: SOLR-10472
> URL: https://issues.apache.org/jira/browse/SOLR-10472
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10472.patch, SOLR-10472.patch, SOLR-10472.patch
>
>
> In getting caught up with the new PointsField work in SOLR-8396 & SOLR-9987 I 
> realized:
> * There's some inconsistencies/contridictions in how the new field types 
> implement {{FieldType.getUninversionType}} vs some of the error handling 
> added to methods like {{SchemaField.checkSortability}}.
> * as part of SOLR-9987, {{SORTED_foo}} constants were added to 
> {{UninvertingReader}} and used in the {{getUninversionType}} methods for 
> PointFields -- even though those constants are useless (because 
> {{UninvertingReader}} doesn't support uninverting multivalued points: 
> SOLR-9202)
> * the changes made to methods like {{SchemaField.checkSortability}} to 
> explicitly check {{isPointsField}} should have never been needed if those 
> methods were paying attention to {{getUninversionType}} -- but those types of 
> checks weren't added when {{getUninversionType}} was introduced (the existing 
> checks pre-date the DocValues API, back where any single-valued indexed field 
> was implicitily "uninvertable")
> * If all of the above is corrected, the only thing preventing 
> {{UninvertedReader}} from working properly with Solr's new PointField types 
> (in the single valued case) is a trivial bug in {{IndexSchema}} (being 
> presumptutious about what is uninvertable)
> I'm opening this issue to track fixing all of this, such that the end result 
> will be:
> * single valued PointFields will be uninvertable (ie: sortable even if they 
> don't have docvalues)
> * error handling code will be simplified
> * unused/unsupported/misleading constants in {{UninvertingReader}} will be 
> removed.



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

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

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[David Smiley]

Hmm; there are a lot of Solr bugs fixed in 6.6 but not yet 6.5.1... I
wonder why others aren't back-porting their fixed bugs?
Lucene has one: LUCENE-  Mike should it be ported to 6.5.1?

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

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

[jira] [Updated] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-10420:
--
Fix Version/s: 6.6

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 6.4.3, 6.5.1, 6.6, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10420:


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

SOLR-10420: fix watcher leak in DistributedQueue


> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 6.4.3, 6.5.1, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



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

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

[jira] [Resolved] (LUCENE-7769) UnifiedHighlighter doesn't highlight MTQs wrapped in BoostQuery

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-7769.
--
   Resolution: Fixed
 Assignee: David Smiley
Fix Version/s: 6.5.1
   master (7.0)

> UnifiedHighlighter doesn't highlight MTQs wrapped in BoostQuery
> ---
>
> Key: LUCENE-7769
> URL: https://issues.apache.org/jira/browse/LUCENE-7769
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 6.5, 6.4.2
>Reporter: Dmitry Malinin
>Assignee: David Smiley
> Fix For: master (7.0), 6.5.1
>
> Attachments: LUCENE_7769_MTQ_in_BoostQuery.patch
>
>
> UnifiedHighlighter doesn't highlight MTQ wrapped in BoostQuery.
> For example, suppose we have a doc with a field 'f' contains data 'lucene'. 
> UnifiedHighlighter highlights query _(f:lucene*)_, but query _(f:lucene*)^1_ 
> doesn't. Test code:
> {code}
> String field = "f";
> String content = "lucene";
> Term term = new Term(field, content);
> UnifiedHighlighter highlighter = new UnifiedHighlighter(null, new 
> StandardAnalyzer());
> Query[] queries = {new PrefixQuery(term), new BoostQuery(new 
> PrefixQuery(term), 1.0f)};
> Object fragObj;   
> for (Query query : queries)
> {
>   fragObj = highlighter.highlightWithoutSearcher(field, query, content, 
> 1);
>   System.out.printf("content=[%s]  Query=%s  frag=[%s]\n", content, 
> query, fragObj);
> }
> {code}
> My opinion it's because MultiTermHighlighting.extractAutomata() returns an 
> empty automaton for BoostQuery. I think, should add some thing like:
> {code}
> if (query instanceof BoostQuery) 
> {
>   list.addAll(Arrays.asList(extractAutomata(((BoostQuery) 
> query).getQuery(), fieldMatcher, lookInSpan, preRewriteFunc))) ; 
> } 
> {code}
> to MultiTermHighlighting.extractAutomata()
> Thanks.



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

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

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

[cpoerschke]

Github user cpoerschke commented on the issue:

https://github.com/apache/lucene-solr/pull/189
  
Hi Judith - I've just gone to 
https://github.com/cpoerschke/lucene-solr/settings/collaboration and invited 
you as a collaborator for my lucene-solr fork here on github. If you'd be happy 
to do the same then we can send each other pull requests. The two top commits 
on https://github.com/cpoerschke/lucene-solr/tree/jira/solr-6203 as one PR for 
example, easier to send a PR rather than comment in the code? Thanks. - 
Christine


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

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

[jira] [Updated] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-10420:
--
Fix Version/s: master (7.0)
   6.5.1
   6.4.3
   5.5.5

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Fix For: 5.5.5, 6.4.3, 6.5.1, master (7.0)
>
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-10420:
---

Great!  Thanks [~steve_rowe]!  I'll get this committed.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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=15973214#comment-15973214
 ] 

Erik Hatcher commented on SOLR-1485:


[~dsmiley] - I wasn't quite sure how to use {{ToDoubleFunction}} in this case, 
but I took a stab at a lambda with an interface.  Payloads really need an 
encoder/decoder coupled utility anyway, so this is a start along that idea as 
well.

> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, 
> SOLR-1485.patch, SOLR-1485.patch
>
>
> Solr 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] (LUCENE-7769) UnifiedHighlighter doesn't highlight MTQs wrapped in BoostQuery

[ASF subversion and git services (JIRA)]

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

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

Commit 3176e650b250af6eb08a3ff6b073c5b649b7e467 in lucene-solr's branch 
refs/heads/branch_6_5 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3176e65 ]

LUCENE-7769: UnifiedHighlighter wasn't seeing inside BoostQuery or 
SpanBoostQuery

(cherry picked from commit 05b101f)


> UnifiedHighlighter doesn't highlight MTQs wrapped in BoostQuery
> ---
>
> Key: LUCENE-7769
> URL: https://issues.apache.org/jira/browse/LUCENE-7769
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 6.5, 6.4.2
>Reporter: Dmitry Malinin
> Attachments: LUCENE_7769_MTQ_in_BoostQuery.patch
>
>
> UnifiedHighlighter doesn't highlight MTQ wrapped in BoostQuery.
> For example, suppose we have a doc with a field 'f' contains data 'lucene'. 
> UnifiedHighlighter highlights query _(f:lucene*)_, but query _(f:lucene*)^1_ 
> doesn't. Test code:
> {code}
> String field = "f";
> String content = "lucene";
> Term term = new Term(field, content);
> UnifiedHighlighter highlighter = new UnifiedHighlighter(null, new 
> StandardAnalyzer());
> Query[] queries = {new PrefixQuery(term), new BoostQuery(new 
> PrefixQuery(term), 1.0f)};
> Object fragObj;   
> for (Query query : queries)
> {
>   fragObj = highlighter.highlightWithoutSearcher(field, query, content, 
> 1);
>   System.out.printf("content=[%s]  Query=%s  frag=[%s]\n", content, 
> query, fragObj);
> }
> {code}
> My opinion it's because MultiTermHighlighting.extractAutomata() returns an 
> empty automaton for BoostQuery. I think, should add some thing like:
> {code}
> if (query instanceof BoostQuery) 
> {
>   list.addAll(Arrays.asList(extractAutomata(((BoostQuery) 
> query).getQuery(), fieldMatcher, lookInSpan, preRewriteFunc))) ; 
> } 
> {code}
> to MultiTermHighlighting.extractAutomata()
> Thanks.



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

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-1485:
---
Attachment: SOLR-1485.patch

implements string checking and lambda creation in ctor instead of nested 
computePayloadFactor function

> Payload scoring support
> ---
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: PayloadTermQueryPlugin.java, payload_value_source.png, 
> SOLR-1485.patch, SOLR-1485.patch
>
>
> Solr 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] (LUCENE-7769) UnifiedHighlighter doesn't highlight MTQs wrapped in BoostQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7769: UnifiedHighlighter wasn't seeing inside BoostQuery or 
SpanBoostQuery


> UnifiedHighlighter doesn't highlight MTQs wrapped in BoostQuery
> ---
>
> Key: LUCENE-7769
> URL: https://issues.apache.org/jira/browse/LUCENE-7769
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 6.5, 6.4.2
>Reporter: Dmitry Malinin
> Attachments: LUCENE_7769_MTQ_in_BoostQuery.patch
>
>
> UnifiedHighlighter doesn't highlight MTQ wrapped in BoostQuery.
> For example, suppose we have a doc with a field 'f' contains data 'lucene'. 
> UnifiedHighlighter highlights query _(f:lucene*)_, but query _(f:lucene*)^1_ 
> doesn't. Test code:
> {code}
> String field = "f";
> String content = "lucene";
> Term term = new Term(field, content);
> UnifiedHighlighter highlighter = new UnifiedHighlighter(null, new 
> StandardAnalyzer());
> Query[] queries = {new PrefixQuery(term), new BoostQuery(new 
> PrefixQuery(term), 1.0f)};
> Object fragObj;   
> for (Query query : queries)
> {
>   fragObj = highlighter.highlightWithoutSearcher(field, query, content, 
> 1);
>   System.out.printf("content=[%s]  Query=%s  frag=[%s]\n", content, 
> query, fragObj);
> }
> {code}
> My opinion it's because MultiTermHighlighting.extractAutomata() returns an 
> empty automaton for BoostQuery. I think, should add some thing like:
> {code}
> if (query instanceof BoostQuery) 
> {
>   list.addAll(Arrays.asList(extractAutomata(((BoostQuery) 
> query).getQuery(), fieldMatcher, lookInSpan, preRewriteFunc))) ; 
> } 
> {code}
> to MultiTermHighlighting.extractAutomata()
> Thanks.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10420:
---

bq. I'm running the full Solr core test suite a couple times now, I'll report 
back when it finishes (should be less than half an hour).

I ran the solr-core and solrj suites three times each with [~dragonsinth]'s 
latest patch on master, and there were zero failures.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-7769) UnifiedHighlighter doesn't highlight MTQs wrapped in BoostQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7769: UnifiedHighlighter wasn't seeing inside BoostQuery or 
SpanBoostQuery

(cherry picked from commit 0ca7a7a)


> UnifiedHighlighter doesn't highlight MTQs wrapped in BoostQuery
> ---
>
> Key: LUCENE-7769
> URL: https://issues.apache.org/jira/browse/LUCENE-7769
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 6.5, 6.4.2
>Reporter: Dmitry Malinin
> Attachments: LUCENE_7769_MTQ_in_BoostQuery.patch
>
>
> UnifiedHighlighter doesn't highlight MTQ wrapped in BoostQuery.
> For example, suppose we have a doc with a field 'f' contains data 'lucene'. 
> UnifiedHighlighter highlights query _(f:lucene*)_, but query _(f:lucene*)^1_ 
> doesn't. Test code:
> {code}
> String field = "f";
> String content = "lucene";
> Term term = new Term(field, content);
> UnifiedHighlighter highlighter = new UnifiedHighlighter(null, new 
> StandardAnalyzer());
> Query[] queries = {new PrefixQuery(term), new BoostQuery(new 
> PrefixQuery(term), 1.0f)};
> Object fragObj;   
> for (Query query : queries)
> {
>   fragObj = highlighter.highlightWithoutSearcher(field, query, content, 
> 1);
>   System.out.printf("content=[%s]  Query=%s  frag=[%s]\n", content, 
> query, fragObj);
> }
> {code}
> My opinion it's because MultiTermHighlighting.extractAutomata() returns an 
> empty automaton for BoostQuery. I think, should add some thing like:
> {code}
> if (query instanceof BoostQuery) 
> {
>   list.addAll(Arrays.asList(extractAutomata(((BoostQuery) 
> query).getQuery(), fieldMatcher, lookInSpan, preRewriteFunc))) ; 
> } 
> {code}
> to MultiTermHighlighting.extractAutomata()
> Thanks.



--
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-6203) cast exception while searching with sort function and result grouping

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-6203:
---

Hi Judith, thanks for merging master into working branch and resolving the 
merge conflict. Sorry I'd gone rather silent here (and otherwise busy 
elsewhere). Alright, let's see if we can wrap this ticket up here soon, git 
branches will definitely help I think :-)

How about this:
* Let's switch to your 
https://github.com/jitka18/lucene-solr/tree/jira/solr-6203 fork of the 
apache:jira/solr-6203 branch as the definitive working branch.
** No need to attach further .patch files to this ticket here (we'll just do 
one 'final' one with the final fix in the end).
** No further updates to the apache:jira/solr-6203 working branch (would it be 
clearer to delete it right away now or only in the end?).

* Next step:
** Could you merge the latest master into the jitka18:jira/solr-6203 and open a 
pull request into apache:master - this will help us 'see' what the changes 
overall are.
** I will add another rename change to SOLR-10394 to help us tell apart actual 
changes from mostly-rename changes.
** I will take a look at and run the tests.


> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
> Attachments: README, SOLR-6203.patch, SOLR-6203.patch, 
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, 
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203-unittest.patch, 
> SOLR-6203-unittest.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic 
> field as text gets a cast exception when using a sort function and result 
> grouping.  
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
> 
> {noformat}
> #  Create  sharded collection
> {noformat}
> curl 
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
>   "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
>   "sort": "sqrt(popularity) desc",
>   "indent": "true",
>   "q": "*:*",
>   "_": "1403709010008",
>   "group.field": "manu",
>   "group": "true",
>   "wt": "json"
> }
>   },
>   "error": {
> "msg": "java.lang.Double cannot be cast to 
> org.apache.lucene.util.BytesRef",
> "code": 500
>   }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException; 
> java.lang.ClassCastException: java.lang.Double cannot be cast to 
> org.apache.lucene.util.BytesRef
> at 
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at 
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
>   ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the 
> {{"*"}} dynamic field, which is a TextField in the repro.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3310/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseG1GC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestSolrCloudWithHadoopAuthPlugin

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at __randomizedtesting.SeedInfo.seed([A38445639E507ACC]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:252)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:49)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:525)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$200(AbstractPollingIoAcceptor.java:67)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:409)
at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
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)




Build Log:
[...truncated 11385 lines...]
   [junit4] Suite: 
org.apache.solr.security.hadoop.TestSolrCloudWithHadoopAuthPlugin
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J1/temp/solr.security.hadoop.TestSolrCloudWithHadoopAuthPlugin_A38445639E507ACC-001/init-core-data-001
   [junit4]   2> 284066 INFO  
(SUITE-TestSolrCloudWithHadoopAuthPlugin-seed#[A38445639E507ACC]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields
   [junit4]   2> 284067 INFO  
(SUITE-TestSolrCloudWithHadoopAuthPlugin-seed#[A38445639E507ACC]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 289668 WARN  
(SUITE-TestSolrCloudWithHadoopAuthPlugin-seed#[A38445639E507ACC]-worker) [] 
o.a.d.s.c.DefaultDirectoryService You didn't change the admin password of 
directory service instance 'DefaultKrbServer'.  Please update the admin 
password as soon as possible to prevent a possible security breach.
   [junit4]   2> 292383 INFO  
(SUITE-TestSolrCloudWithHadoopAuthPlugin-seed#[A38445639E507ACC]-worker) [] 
o.a.s.SolrTestCaseJ4 ###deleteCore
   [junit4]   2> 292383 INFO  
(SUITE-TestSolrCloudWithHadoopAuthPlugin-seed#[A38445639E507ACC]-worker) [] 
o.a.s.SolrTestCaseJ4 --- 
Done waiting for tracked resources to be released
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
docValues:{}, maxPointsInLeafNode=660, maxMBSortInHeap=5.9064958008799255, 
sim=RandomSimilarity(queryNorm=false,coord=no): {}, locale=lv-LV, 
timezone=Antarctica/DumontDUrville
   [junit4]   2> NOTE: Linux 4.4.0-72-generic i386/Oracle Corporation 1.8.0_121 
(32-bit)/cpus=12,threads=1,free=262656200,total=536870912
   [junit4]   2> NOTE: All tests run in this JVM: 
[ManagedSchemaRoundRobinCloudTest, ShufflingReplicaListTransformerTest, 
BasicFunctionalityTest, ClusterStateUpdateTest, InfoHandlerTest, 
TestFastOutputStream, CursorMarkTest, SoftAutoCommitTest, 
SecurityConfHandlerTest, LeaderFailoverAfterPartitionTest, 
CollectionsAPISolrJTest, TestBM25SimilarityFactory, JSONWriterTest, 
HdfsTlogReplayBufferedWhileIndexingTest, TestCloudSchemaless, RulesTest, 
TestImplicitCoreProperties, SaslZkACLProviderTest, RankQueryTest, 
RestartWhileUpdatingTest, TestXmlQParserPlugin, SmileWriterTest, 
RemoteQueryErrorTest, DistanceFunctionTest, TestPivotHelperCode, 
DocumentBuilderTest, DeleteReplicaTest, TestTestInjection, TestRTGBase, 
SortByFunctionTest, SpellCheckCollatorTest, AddBlockUpdateTest, 
QueryResultKeyTest, TestSolrCloudWithHadoopAuthPlugin]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSolrCloudWithHadoopAuthPlugin -Dtests.seed=A38445639E507ACC 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV 
-Dtests.timezone=Antarctica/DumontDUrville -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J1 | TestSolrCloudWithHadoopAuthPlugin (suite) <<<
   [junit4]> Throwable #1: java.net.BindException: Address already in use
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A38445639E507ACC]:0)
   [junit4]>at sun.nio.ch.Net.bind0(Native Method)
   [junit4]>at sun.nio.ch.Net.bind(Net.java:433)
   [junit4]>at sun.nio.ch.Net.bind(Net.java:425)
   [junit4]>  

[jira] [Commented] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10420:
---

I did 500 beasting iterations of OverseerTest using your latest patch 
[~dragonsinth], zero failures.

I'm running the full Solr core test suite a couple times now, I'll report back 
when it finishes (should be less than half an hour).

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



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

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

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[Joel Bernstein]

Sure

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

On Tue, Apr 18, 2017 at 1:20 PM, David Smiley 
wrote:

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

Re: [VOTE] Release Lucene/Solr 6.5.1 RC1

[David Smiley]

I've been sitting on these bug fixes (see below) in case there will be
another RC and now it looks like there will be one.  Joel, shall I commit
them to the release branch?

On Mon, Apr 10, 2017 at 2:47 PM David Smiley 
wrote:

> +1 SUCCESS! [0:48:18.176212]
>
> If there is a respin for any reason, I'd suggest including LUCENE-7769 (UH
> boost query) and SOLR-10439 ('large' and SchemaField)
>
> ~ David
>
> On Mon, Apr 10, 2017 at 2:07 PM Adrien Grand  wrote:
>
> +1 SUCCESS! [1:46:31.647123]
>
> Le lun. 10 avr. 2017 à 05:01, Joel Bernstein  a
> écrit :
>
> Please vote for release candidate 1 for Lucene/Solr 6.5.1The artifacts can be 
> downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>
> You can run the smoke tester directly with this command:python3 -u 
> dev-tools/scripts/smokeTestRelease.py 
> \https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.1-RC1-revf88f850034eee845b8021af47ecffc9c42aa8539
>
> Here's my +1
>
> SUCCESS! [0:40:54.049621]
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Solr JMX changes and backwards (in)compatibility

[Walter Underwood]

Pretty sure the back-compat did not work, because New Relic cannot find the 
MBeans in our 6.5.0 cluster.

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


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

[jira] [Comment Edited] (SOLR-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum edited comment on SOLR-10420 at 4/18/17 5:14 PM:


Agreed.  It passes for me.  Anyone on this issue want to do any extensive 
testing of 
https://issues.apache.org/jira/secure/attachment/12863715/SOLR-10420-dragonsinth.patch
 before I commit?  Otherwise I'll commit this today to master and then start 
backporting it to a number of branches.


was (Author: dragonsinth):
Agreed.  It passes for me.  Anyone on this issue want to do any extensive 
testing before I commit?  Otherwise I'll commit this today to master and then 
start backporting it to a number of branches.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-10420:
---

Agreed.  It passes for me.  Anyone on this issue want to do any extensive 
testing before I commit?  Otherwise I'll commit this today to master and then 
start backporting it to a number of branches.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



--
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-10420) Solr 6.x leaking one SolrZkClient instance per second

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-10420:
-

[~dragonsinth] This issue is blocker for Solr 6.5.1. So I think we (you) should 
commit soon.

> Solr 6.x leaking one SolrZkClient instance per second
> -
>
> Key: SOLR-10420
> URL: https://issues.apache.org/jira/browse/SOLR-10420
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2, 6.4.2, 6.5
>Reporter: Markus Jelsma
>Assignee: Scott Blum
> Attachments: OverseerTest.106.stdout, OverseerTest.119.stdout, 
> OverseerTest.80.stdout, OverseerTest.DEBUG.43.stdout, 
> OverseerTest.DEBUG.48.stdout, OverseerTest.DEBUG.58.stdout, 
> SOLR-10420-dragonsinth.patch, SOLR-10420.patch, SOLR-10420.patch, 
> SOLR-10420.patch, SOLR-10420.patch, SOLR-10420.patch
>
>
> One of our nodes became berzerk after a restart, Solr went completely nuts! 
> So i opened VisualVM to keep an eye on it and spotted a different problem 
> that occurs in all our Solr 6.4.2 and 6.5.0 nodes.
> It appears Solr is leaking one SolrZkClient instance per second via 
> DistributedQueue$ChildWatcher. That one per second is quite accurate for all 
> nodes, there are about the same amount of instances as there are seconds 
> since Solr started. I know VisualVM's instance count includes 
> objects-to-be-collected, the instance count does not drop after a forced 
> garbed collection round.
> It doesn't matter how many cores or collections the nodes carry or how heavy 
> traffic is.



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