[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7188:
--

I think you're right Yonik.  At first I was about to disagree to write that we 
should fix this by having listAll hold both locks, but I now think there's no 
point to it.  We know exactly why listAll can momentarily find a file in both 
places, and it's okay. It's a race condition of no consequence.  The file is 
still there to return from listAll; we know what to do.  There are other race 
conditions of no consequences too that have comments {{"// Another thread beat 
us..."}}.

listAll can use Collections.addAll like so to replace two for loops:
{code:java}
Collections.addAll(files, cache.listAll());
Collections.addAll(files, in.listAll());
{code}

I'm unsure why listAll needs any synchronization at all, for that matter.  It's 
an omission that the Directory API says nothing about thread-safety; 
nevertheless I assume instances should be thread-safe.  

Everything below could be its own JIRA issue:

Can we remove _all_ synchronization on "this" (not substituting it with 
anything else either) and change methods to not use/depend on calling 
{{cache.fileNameExists()}}?  Using that method as a guard is, I think, what led 
to synchronizing on "this" in the first place.  For example, fileLength could 
be rewritten to this:
{code:java}
public long fileLength(String name) throws IOException {
try {
  return cache.fileLength(name);
} catch (FileNotFoundException | NoSuchFileException e) {
  return in.fileLength(name);
}
  }
{code}
 -- and likewise for deleteFile and openInput.  Then the synchronized(this) 
inside unCache can be removed too, leaving none left.

unCache calls {{cache.fileNameExists()}} too but I think it's okay since it 
merely exits early.   

unCache's use of uncacheLock could probably be changed to be a per-file name 
lock instead of one shared lock for the directory instance since it only needs 
to lock per file name it's un-caching.  Although I'm not sure it's worth the 
complexity bothering.

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>Assignee: Yonik Seeley
> Fix For: master, 6.1, 5.5.1
>
> Attachments: LUCENE-7188.patch
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> 

Re: [JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 514 - Failure!

[Tommaso Teofili]

thanks for fixing it Adrien.

Regards,
Tommaso

Il giorno mar 12 apr 2016 alle ore 01:08 Chris Hostetter <
hossman_luc...@fucit.org> ha scritto:

>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/88965a0b
>
> : Date: Mon, 11 Apr 2016 14:11:31 -0400
> : From: Michael McCandless 
> : Reply-To: dev@lucene.apache.org
> : To: Policeman Jenkins Server 
> : Cc: m...@apache.org, tomm...@apache.org,
> : Varun Thacker ,
> : Robert Muir , Lucene/Solr dev <
> dev@lucene.apache.org>
> : Subject: Re: [JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) -
> Build #
> : 514 - Failure!
> :
> : Is this saying that classification javadocs are angry?
> :
> : Mike McCandless
> :
> : http://blog.mikemccandless.com
> :
> : On Mon, Apr 11, 2016 at 1:41 PM, Policeman Jenkins Server <
> : jenk...@thetaphi.de> wrote:
> :
> : > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/514/
> : > Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
> : >
> : > All tests passed
> : >
> : > Build Log:
> : > [...truncated 53072 lines...]
> : >   [javadoc] Generating Javadoc
> : >   [javadoc] Javadoc execution
> : >   [javadoc] Loading source files for package
> : > org.apache.lucene.classification...
> : >   [javadoc] Loading source files for package
> : > org.apache.lucene.classification.document...
> : >   [javadoc] Loading source files for package
> : > org.apache.lucene.classification.utils...
> : >   [javadoc] Constructing Javadoc information...
> : >   [javadoc] javadoc: warning - Error reading file:
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/docs/classification/../group/package-list
> : >   [javadoc] Standard Doclet version 1.8.0_72
> : >   [javadoc] Building tree for all the packages and classes...
> : >   [javadoc] Building index for all the packages and classes...
> : >   [javadoc] Building index for all classes...
> : >   [javadoc] Generating
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/docs/classification/help-doc.html...
> : >   [javadoc] Note: Custom tags that were not seen:  @lucene.internal
> : >   [javadoc] 1 warning
> : >
> : > BUILD FAILED
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:740:
> : > The following error occurred while executing this line:
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:101:
> : > The following error occurred while executing this line:
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:138:
> : > The following error occurred while executing this line:
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:246:
> : > The following error occurred while executing this line:
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2187:
> : > The following error occurred while executing this line:
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/classification/build.xml:46:
> : > The following error occurred while executing this line:
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:78:
> : > The following error occurred while executing this line:
> : >
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2163:
> : > Javadocs warnings were found!
> : >
> : > Total time: 88 minutes 41 seconds
> : > Build step 'Invoke Ant' marked build as failure
> : > Archiving artifacts
> : > [WARNINGS] Skipping publisher since build result is FAILURE
> : > Recording test results
> : > Email was triggered for: Failure - Any
> : > Sending email for trigger: Failure - Any
> : >
> : >
> :
>
> -Hoss
> http://www.lucidworks.com/
>

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 69 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/69/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"", "path":"/test1", "httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val' for path 'x' 
full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null}
at 
__randomizedtesting.SeedInfo.seed([F059737B5C054FBF:28145E2CABD8EA1F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:238)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7202:
-

Another proposal:

GeoPoint: 1 dimension with morton z encoding -> GeoMortonZLatLonPoint
LatLonPoint: 2 dimensions -> GeoLatLonPoint
Geo3dPoint: 3 dimensions -> GeoXYZPoint

> Come up with a comprehensive proposal for naming spatial modules and 
> technologies
> -
>
> Key: LUCENE-7202
> URL: https://issues.apache.org/jira/browse/LUCENE-7202
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/sandbox, modules/spatial, modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, 
> and nobody seems happy with the naming of them.  For each implementation 
> strategy, we need both a module name and a descriptive technology name that 
> we can use to distinguish one from the other.  I would expect the following 
> people to have an interest in this process: [~rcmuir], [~dsmiley], 
> [~mikemccand], etc.



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

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

[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7202:
-

One proposal:

GeoPoint: 1 dimension with morton z encoding -> Geo1DPoint
LatLonPoint: 2 dimensions -> Geo2DPoint
Geo3dPoint: 3 dimensions -> Geo3DPoint



> Come up with a comprehensive proposal for naming spatial modules and 
> technologies
> -
>
> Key: LUCENE-7202
> URL: https://issues.apache.org/jira/browse/LUCENE-7202
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/sandbox, modules/spatial, modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, 
> and nobody seems happy with the naming of them.  For each implementation 
> strategy, we need both a module name and a descriptive technology name that 
> we can use to distinguish one from the other.  I would expect the following 
> people to have an interest in this process: [~rcmuir], [~dsmiley], 
> [~mikemccand], etc.



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

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

[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7202:
-

I would disagree that LatLonPoint is sufficiently descriptive.  All of the 
implementations have latitudes, longitudes, and points.


> Come up with a comprehensive proposal for naming spatial modules and 
> technologies
> -
>
> Key: LUCENE-7202
> URL: https://issues.apache.org/jira/browse/LUCENE-7202
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/sandbox, modules/spatial, modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, 
> and nobody seems happy with the naming of them.  For each implementation 
> strategy, we need both a module name and a descriptive technology name that 
> we can use to distinguish one from the other.  I would expect the following 
> people to have an interest in this process: [~rcmuir], [~dsmiley], 
> [~mikemccand], etc.



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

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

[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7202:
-

+1, though, for fewer modules.

> Come up with a comprehensive proposal for naming spatial modules and 
> technologies
> -
>
> Key: LUCENE-7202
> URL: https://issues.apache.org/jira/browse/LUCENE-7202
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/sandbox, modules/spatial, modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, 
> and nobody seems happy with the naming of them.  For each implementation 
> strategy, we need both a module name and a descriptive technology name that 
> we can use to distinguish one from the other.  I would expect the following 
> people to have an interest in this process: [~rcmuir], [~dsmiley], 
> [~mikemccand], etc.



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

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

[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7202:
-

Another way to see it: imagine there are 3 public classes:

* GeoPoint: 1 dimension with morton z encoding 
* LatLonPoint: 2 dimensions
* Geo3dPoint: 3 dimensions

What better names can these classes have? I think this is a better place to 
start than worrying about modules. And i do honestly feel we can just have 
these 3 classes (and only these 3) public. I also know for a fact the 3d causes 
confusion with elevation, yes, practically if you want to do that, just index 
an integer field totally unrelated with any of these and people will be happy. 
But we should eliminate confusion.

> Come up with a comprehensive proposal for naming spatial modules and 
> technologies
> -
>
> Key: LUCENE-7202
> URL: https://issues.apache.org/jira/browse/LUCENE-7202
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/sandbox, modules/spatial, modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, 
> and nobody seems happy with the naming of them.  For each implementation 
> strategy, we need both a module name and a descriptive technology name that 
> we can use to distinguish one from the other.  I would expect the following 
> people to have an interest in this process: [~rcmuir], [~dsmiley], 
> [~mikemccand], etc.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_72) - Build # 16488 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16488/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'first' for path 
'response/params/x/_appends_/add' full output: {   "responseHeader":{ 
"status":0, "QTime":0},   "response":{ "znodeVersion":3, "params":{ 
  "x":{ "a":"A val", "b":"B val", "":{"v":0}},  
 "y":{ "p":"P val", "q":"Q val", "":{"v":2}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'first' for path 
'response/params/x/_appends_/add' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":3,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
  "y":{
"p":"P val",
"q":"Q val",
"":{"v":2}
at 
__randomizedtesting.SeedInfo.seed([F2F4DAE4F3EFEB16:7AA0E53E5D1386EE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:458)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:236)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7202:
-

Less modules not more. I already explained how modules are just as confusing as 
bad naming (bad packaging all around). I don't think we should create a module 
for a single public class.

{quote}
Until we determine elevation-specific functionality, 3D is a meaningful moniker
{quote}

Ok then what are we doing here? Because e.g. LatLonPoint is a very simple name, 
usable to the layman. Putting this in a package with a complex name like 
spatial-planar hurts it, when it was never confusing to begin with :)




> Come up with a comprehensive proposal for naming spatial modules and 
> technologies
> -
>
> Key: LUCENE-7202
> URL: https://issues.apache.org/jira/browse/LUCENE-7202
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/sandbox, modules/spatial, modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, 
> and nobody seems happy with the naming of them.  For each implementation 
> strategy, we need both a module name and a descriptive technology name that 
> we can use to distinguish one from the other.  I would expect the following 
> people to have an interest in this process: [~rcmuir], [~dsmiley], 
> [~mikemccand], etc.



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

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

[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7202:
-

Also, one other thing to note: There has been discussion of the usage of 3D and 
the confusion that might have with implementations that support elevation.  My 
thought is that *all* implementations currently "support elevation", because we 
don't actually do anything of consequence at the API level with elevation 
information.  Until we determine elevation-specific functionality, 3D *is* a 
meaningful moniker.  But I agree it is not specific enough in the long run.



> Come up with a comprehensive proposal for naming spatial modules and 
> technologies
> -
>
> Key: LUCENE-7202
> URL: https://issues.apache.org/jira/browse/LUCENE-7202
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/sandbox, modules/spatial, modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, 
> and nobody seems happy with the naming of them.  For each implementation 
> strategy, we need both a module name and a descriptive technology name that 
> we can use to distinguish one from the other.  I would expect the following 
> people to have an interest in this process: [~rcmuir], [~dsmiley], 
> [~mikemccand], etc.



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

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

[jira] [Comment Edited] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Karl Wright (JIRA)]

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

Karl Wright edited comment on LUCENE-7202 at 4/12/16 4:32 AM:
--

My proposal is as follows:  The module names would include:
- spatial-ellipsoid
- spatial-plane
- (+ one other TBD, since I don't know what really distinguishes the "point" 
implementation from the other 2D implementation)

The implementation strategies could be called "ellipsoidal" or "planar" 
correspondingly.




was (Author: kwri...@metacarta.com):
My proposal is as follows:  The module names would include:
- spatial-ellipsoid
- spatial-planar
- (+ one other TBD, since I don't know what really distinguishes the "point" 
implementation from the other 2D implementation)

The implementation strategies could be called "ellipsoidal" or "planar" 
correspondingly.



> Come up with a comprehensive proposal for naming spatial modules and 
> technologies
> -
>
> Key: LUCENE-7202
> URL: https://issues.apache.org/jira/browse/LUCENE-7202
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/sandbox, modules/spatial, modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, 
> and nobody seems happy with the naming of them.  For each implementation 
> strategy, we need both a module name and a descriptive technology name that 
> we can use to distinguish one from the other.  I would expect the following 
> people to have an interest in this process: [~rcmuir], [~dsmiley], 
> [~mikemccand], etc.



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

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

[jira] [Commented] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7202:
-

My proposal is as follows:  The module names would include:
- spatial-ellipsoid
- spatial-planar
- (+ one other TBD, since I don't know what really distinguishes the "point" 
implementation from the other 2D implementation)

The implementation strategies could be called "ellipsoidal" or "planar" 
correspondingly.



> Come up with a comprehensive proposal for naming spatial modules and 
> technologies
> -
>
> Key: LUCENE-7202
> URL: https://issues.apache.org/jira/browse/LUCENE-7202
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/sandbox, modules/spatial, modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>
> There are three different spatial implementations circulating at the moment, 
> and nobody seems happy with the naming of them.  For each implementation 
> strategy, we need both a module name and a descriptive technology name that 
> we can use to distinguish one from the other.  I would expect the following 
> people to have an interest in this process: [~rcmuir], [~dsmiley], 
> [~mikemccand], etc.



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

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

[jira] [Created] (LUCENE-7202) Come up with a comprehensive proposal for naming spatial modules and technologies

[Karl Wright (JIRA)]

Karl Wright created LUCENE-7202:
---

 Summary: Come up with a comprehensive proposal for naming spatial 
modules and technologies
 Key: LUCENE-7202
 URL: https://issues.apache.org/jira/browse/LUCENE-7202
 Project: Lucene - Core
  Issue Type: Task
  Components: modules/sandbox, modules/spatial, modules/spatial3d
Affects Versions: master
Reporter: Karl Wright


There are three different spatial implementations circulating at the moment, 
and nobody seems happy with the naming of them.  For each implementation 
strategy, we need both a module name and a descriptive technology name that we 
can use to distinguish one from the other.  I would expect the following people 
to have an interest in this process: [~rcmuir], [~dsmiley], [~mikemccand], etc.



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

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

[jira] [Commented] (SOLR-8929) Add an idea module for solr/server to enable launching start.jar

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8929:
--

Thanks for looking at this.  I don't think calling the bin/solr script is as 
good of a workflow, however.  If you have the right classpath setup in 
IntelliJ, the edit/debug cycle is really fast; you can make code changes, 
restart the debugger, and you're good to go.  The bin/solr script requires jars 
to be rebuilt or you won't be up to date with the latest code.

The whole point of using an IDE and having an IntelliJ project is for maximum 
productivity, and having a module setup that enables really running solr as a 
debug config is maximally productive.

> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([AAA627074DC8AC4E:1327F1D86122A8C4]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:780)
at 
org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:198)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


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




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

[jira] [Resolved] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved LUCENE-7188.
--
   Resolution: Fixed
Fix Version/s: 5.5.1
   master

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>Assignee: Yonik Seeley
> Fix For: master, 6.1, 5.5.1
>
> Attachments: LUCENE-7188.patch
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, _9v_Lucene50_0.tim, 
> _9v_Lucene50_0.tip, _9w.fdt, _9w.fdx, _9w.fnm, _9w.nvd, _9w.nvm, _9w.si, 
> _9w_Lucene50_0.doc, _9w_Lucene50_0.pos, _9w_Lucene50_0.tim, 
> _9w_Lucene50_0.tip, _9x.fdt, _9x.fdx, _9x.fnm, _9x.nvd, _9x.nvm, 

[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7188: remove incorrect sanity check in NRTCachingDirectory.listAll() 
that throws IllegalStateException


> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>Assignee: Yonik Seeley
> Fix For: 6.1
>
> Attachments: LUCENE-7188.patch
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, 

[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[ASF subversion and git services (JIRA)]

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

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

Commit a49b748b58b31af51d06c1d360777d679285e8fd in lucene-solr's branch 
refs/heads/branch_5_5 from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a49b748 ]

LUCENE-7188: remove incorrect sanity check in NRTCachingDirectory.listAll() 
that throws IllegalStateException


> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>Assignee: Yonik Seeley
> Fix For: 6.1
>
> Attachments: LUCENE-7188.patch
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, 

[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7188: remove incorrect sanity check in NRTCachingDirectory.listAll() 
that throws IllegalStateException


> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>Assignee: Yonik Seeley
> Fix For: 6.1
>
> Attachments: LUCENE-7188.patch
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, 

[jira] [Assigned] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[Yonik Seeley (JIRA)]

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

Yonik Seeley reassigned LUCENE-7188:


Assignee: Yonik Seeley

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>Assignee: Yonik Seeley
> Fix For: 6.1
>
> Attachments: LUCENE-7188.patch
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, _9v_Lucene50_0.tim, 
> _9v_Lucene50_0.tip, _9w.fdt, _9w.fdx, _9w.fnm, _9w.nvd, _9w.nvm, _9w.si, 
> _9w_Lucene50_0.doc, _9w_Lucene50_0.pos, _9w_Lucene50_0.tim, 
> _9w_Lucene50_0.tip, _9x.fdt, _9x.fdx, _9x.fnm, _9x.nvd, _9x.nvm, _9x.si, 
> _9x_Lucene50_0.doc, _9x_Lucene50_0.pos, 

Explain seems weird after LUCENE-6590/6783, possible bug?

[Erick Erickson]

I was asked a question "why does the explain report boost as queryNorm
in 5x?" by a sharp-eyed person who traced it back to the
FunctionQuery.explain method.

So I looked into the code and LUCENE-6590/LUCENE-6783 changed
FunctionQuery.explain(int doc) to
FunctionQueyr.explain(int doc, float queryNorm).

So far, so good. But within that function

Explanation.match(getBoost(), "boost"), changed to:
Explanation.match(queryNorm, "boost"),

which is puzzling. Should I raise a JIRA?

Erick

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

[jira] [Updated] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated LUCENE-7188:
-
Attachment: LUCENE-7188.patch

Removing the current check makes the most sense.  It makes less sense to fail 
this single read-only method (and not fail any others) if we detect something 
has gone wrong.

If there is a desire for more sanity checking (and we can figure out a coherent 
behavior for when something bad is detected) then that can be handled in a new 
JIRA issue.

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
> Fix For: 6.1
>
> Attachments: LUCENE-7188.patch
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/70/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations

Error Message:
invalid hits for shape=GeoCompositeMembershipShape: {[GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=0.2669499069140678, 
lon=-0.31249902828113546([X=0.9186752334433793, Y=-0.2968103450748192, 
Z=0.2640238502385029])], [lat=1.538559019421765, 
lon=0.0([X=0.03215971057004023, Y=0.0, Z=0.9972473454662941])], 
[lat=-0.5516194571595735, lon=0.0([X=0.8518418310766115, Y=0.0, 
Z=-0.5241686363384119])]], internalEdges={2}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=0.0, 
lon=-3.141592653589793([X=-1.0011188539924791, Y=-1.226017000107956E-16, 
Z=0.0])], [lat=-1.5707963267948966, 
lon=-2.2780601241431375([X=-3.9697069088211677E-17, Y=-4.644115432258393E-17, 
Z=-0.997762292022105])], [lat=0.2669499069140678, 
lon=-0.31249902828113546([X=0.9186752334433793, Y=-0.2968103450748192, 
Z=0.2640238502385029])]], internalEdges={2}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=0.2669499069140678, 
lon=-0.31249902828113546([X=0.9186752334433793, Y=-0.2968103450748192, 
Z=0.2640238502385029])], [lat=-0.5516194571595735, 
lon=0.0([X=0.8518418310766115, Y=0.0, Z=-0.5241686363384119])], [lat=0.0, 
lon=-3.141592653589793([X=-1.0011188539924791, Y=-1.226017000107956E-16, 
Z=0.0])]], internalEdges={0, 2}}]}

Stack Trace:
java.lang.AssertionError: invalid hits for shape=GeoCompositeMembershipShape: 
{[GeoConvexPolygon: {planetmodel=PlanetModel.WGS84, 
points=[[lat=0.2669499069140678, 
lon=-0.31249902828113546([X=0.9186752334433793, Y=-0.2968103450748192, 
Z=0.2640238502385029])], [lat=1.538559019421765, 
lon=0.0([X=0.03215971057004023, Y=0.0, Z=0.9972473454662941])], 
[lat=-0.5516194571595735, lon=0.0([X=0.8518418310766115, Y=0.0, 
Z=-0.5241686363384119])]], internalEdges={2}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=0.0, 
lon=-3.141592653589793([X=-1.0011188539924791, Y=-1.226017000107956E-16, 
Z=0.0])], [lat=-1.5707963267948966, 
lon=-2.2780601241431375([X=-3.9697069088211677E-17, Y=-4.644115432258393E-17, 
Z=-0.997762292022105])], [lat=0.2669499069140678, 
lon=-0.31249902828113546([X=0.9186752334433793, Y=-0.2968103450748192, 
Z=0.2640238502385029])]], internalEdges={2}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=0.2669499069140678, 
lon=-0.31249902828113546([X=0.9186752334433793, Y=-0.2968103450748192, 
Z=0.2640238502385029])], [lat=-0.5516194571595735, 
lon=0.0([X=0.8518418310766115, Y=0.0, Z=-0.5241686363384119])], [lat=0.0, 
lon=-3.141592653589793([X=-1.0011188539924791, Y=-1.226017000107956E-16, 
Z=0.0])]], internalEdges={0, 2}}]}
at 
__randomizedtesting.SeedInfo.seed([3B0F8F9FC5B270DA:8B70F20B4AFFDE46]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations(TestGeo3DPoint.java:434)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_72) - Build # 16487 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16487/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Error from server at http://127.0.0.1:46377/sbzor/h/collection1: Async 
exception during distributed update: Bad Requestrequest: 
http://127.0.0.1:38620/sbzor/h/collection1/update?update.chain=distrib-dup-test-chain-explicit=TOLEADER=http%3A%2F%2F127.0.0.1%3A46377%2Fsbzor%2Fh%2Fcollection1%2F=javabin=2

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:46377/sbzor/h/collection1: Async exception 
during distributed update: Bad Request



request: 
http://127.0.0.1:38620/sbzor/h/collection1/update?update.chain=distrib-dup-test-chain-explicit=TOLEADER=http%3A%2F%2F127.0.0.1%3A46377%2Fsbzor%2Fh%2Fcollection1%2F=javabin=2
at 
__randomizedtesting.SeedInfo.seed([CA3B1243947FA8E7:426F2D993A83C51F]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.BaseDistributedSearchTestCase.add(BaseDistributedSearchTestCase.java:507)
at 
org.apache.solr.cloud.BasicDistributedZkTest.testUpdateProcessorsRunOnlyOnce(BasicDistributedZkTest.java:670)
at 
org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:365)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)

[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet

[Matt Weber (JIRA)]

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

Matt Weber commented on SOLR-7495:
--

group.facet also breaks range queries.  I'm finding v5 almost non-usable.

I tried setting docValues to true on the fields (and re-indexing), but it 
hasn't worked differently.

The only workaround I found was using facet queries with multi-valued fields, 
but that doesn't help with everything.

The work around doesn't apply to range facets.

For example:

This works...

=rounded_price_price.facet.range.start=0_price.facet.range.end=100_price.facet.range.gap=10=on

But simply adding "group.facet" fails...

=rounded_price_price.facet.range.start=0_price.facet.range.end=100_price.facet.range.gap=10=on=true=anyNumericField

> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL: https://issues.apache.org/jira/browse/SOLR-7495
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
> Attachments: SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year' 
> (expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
> 
> 
> 
> 
> 
> 
>  multiValued="false" required="true"/>
>  multiValued="false" required="true"/>
> 
> 
>  stored="true"/>
> 
> 
> 
>  />
>  sortMissingLast="true"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  precisionStep="0" positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" 
> distErrPct="0.025" maxDistErr="0.09" units="degrees" />
> 
> id
> name
> 
> 
> {code}
> query :
> {code}
> http://solr.dev:8983/solr/my_collection/select?wt=json=id=index_type:foobar=true=year_make_model=true=true=year
> {code}
> Exception :
> {code}
> ull:org.apache.solr.common.SolrException: Exception during facet.field: year
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
> at 
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
> at 
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at 
> 

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

[Joseph Lawson (JIRA)]

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

Joseph Lawson commented on SOLR-8970:
-

It would be nice if the keystore blob was included in the test jar so that 
reusing SolrTestCaseJ4 in projects wouldn't require much setup beyond extending 
or just using the class. Letting it be overridden via sysprops is good too.

> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



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

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

[jira] [Updated] (LUCENE-7200) stop word/punctuation QueryParser error(return all records)

[Littlestar (JIRA)]

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

Littlestar updated LUCENE-7200:
---
Priority: Minor  (was: Major)

> stop word/punctuation QueryParser error(return all records)
> ---
>
> Key: LUCENE-7200
> URL: https://issues.apache.org/jira/browse/LUCENE-7200
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.10.4, 5.4.1
>Reporter: Littlestar
>Priority: Minor
>
> when user input some stop words or punctuation.
> It return all records??
> {code}
>   @Test
> public void test01() throws ParseException {
> QueryParser parser = new QueryParser("test", new CJKAnalyzer());
> Query parse = parser.parse("test:hello AND (a)");
> //Query parse = parser.parse("test:hello AND (;)");
> System.out.println(parse.toString());
> }
> {code}
> Does "test:hello AND (a)"  === "test:hello"
> thanks?



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

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

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8970:


as things stand now, combined with SOLR-8971, this problem manifests itself in 
user tests in the most obtuse way possible...

{noformat}
Date: Mon, 11 Apr 2016 12:29:42 -0400
From: Joe Lawson
Subject: Solr 6 - AbstractSolrTestCase Error Unable to build KeyStore from 
file: null

I'm upgrading a plugin and use the AbstractSolrTestCase for tests. My tests
work fine in 5.X but when I upgraded to 6.X the tests sometimes throw an
error during initialization. Basically it says,
"org.apache.solr.common.SolrException: Error instantiating
shardHandlerFactory class
[org.apache.solr.handler.component.HttpShardHandlerFactory]: Unable to
build KeyStore from file: null"

...

> NOTE: reproduce with: ant test  -Dtestcase=TestConstructedPhrases
>> -Dtests.seed=48D5F3D29EAB417 -Dtests.locale=en
>> -Dtests.timezone=America/Blanc-Sablon -Dtests.asserts=true
>> -Dtests.file.encoding=UTF-8
>
>
>> org.apache.solr.common.SolrException: Error instantiating
>> shardHandlerFactory class
>> [org.apache.solr.handler.component.HttpShardHandlerFactory]: Unable to
>> build KeyStore from file: null
>
>
>> at __randomizedtesting.SeedInfo.seed([48D5F3D29EAB417]:0)
>
> at
>> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:52)
>
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:404)
>
> at org.apache.solr.util.TestHarness.(TestHarness.java:164)
>
> at org.apache.solr.util.TestHarness.(TestHarness.java:127)
>
> at org.apache.solr.util.TestHarness.(TestHarness.java:133)
>
> at org.apache.solr.util.TestHarness.(TestHarness.java:96)
>
> at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:598)
>
> at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:588)
>
> at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:430)
>
> at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:419)
>
> at
>> org.apache.solr.search.HonLuceneSynonymTestCase.beforeClass(HonLuceneSynonymTestCase.java:36)
{noformat}

> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



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

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

[jira] [Updated] (LUCENE-7200) stop word/punctuation QueryParser error(return all records)

[Littlestar (JIRA)]

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

Littlestar updated LUCENE-7200:
---
Description: 
when user input some stop words or punctuation.
It return all records??
{code}
  @Test
public void test01() throws ParseException {
QueryParser parser = new QueryParser("test", new CJKAnalyzer());
Query parse = parser.parse("test:hello AND (a)");
//Query parse = parser.parse("test:hello AND (;)");
System.out.println(parse.toString());
}
{code}

Does "test:hello AND (a)"  === "test:hello"

thanks?

  was:
when user input some stop words or punctuation.
It return all records??

  @Test
public void test01() throws ParseException {
QueryParser parser = new QueryParser("test", new CJKAnalyzer());
Query parse = parser.parse("test:hello AND (a)");
//Query parse = parser.parse("test:hello AND (;)");
System.out.println(parse.toString());
}

Does "test:hello AND (a)"  === "test:hello"

thanks?


> stop word/punctuation QueryParser error(return all records)
> ---
>
> Key: LUCENE-7200
> URL: https://issues.apache.org/jira/browse/LUCENE-7200
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.10.4, 5.4.1
>Reporter: Littlestar
>
> when user input some stop words or punctuation.
> It return all records??
> {code}
>   @Test
> public void test01() throws ParseException {
> QueryParser parser = new QueryParser("test", new CJKAnalyzer());
> Query parse = parser.parse("test:hello AND (a)");
> //Query parse = parser.parse("test:hello AND (;)");
> System.out.println(parse.toString());
> }
> {code}
> Does "test:hello AND (a)"  === "test:hello"
> thanks?



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

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

[jira] [Created] (SOLR-8971) ShardHandlerFactory error handling throws away exception details

[Hoss Man (JIRA)]

Hoss Man created SOLR-8971:
--

 Summary: ShardHandlerFactory error handling throws away exception 
details
 Key: SOLR-8971
 URL: https://issues.apache.org/jira/browse/SOLR-8971
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


ShardHandlerFactory.newInstance catches any Exception from initializing the 
configured ShardHandlerFactory class as a plugin, and then throws a new 
SolrException w/o wrapping hte original excpetion - losing all useful context 
of why the plugin couldn't be loaded.



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

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

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8970:


SSLTestConfig already sanity checks whether TEST_KEYSTORE exists...
{code}
  public static File TEST_KEYSTORE = ExternalPaths.SERVER_HOME == null ? null
  : new File(ExternalPaths.SERVER_HOME, "../etc/test/solrtest.keystore");  
  private static String TEST_KEYSTORE_PATH = TEST_KEYSTORE != null
  && TEST_KEYSTORE.exists() ? TEST_KEYSTORE.getAbsolutePath() : null;
{code}

We should...

* change how TEST_KEYSTORE_PATH is initialized so that people using 
SolrTestCaseJ4/SSLTestConfig can set a sysprop when running tests to change 
which path to use when looking for the file
* change SSLTestConfig's constructors so that if {{clientAuth==true}} but 
{{TEST_KEYSTORE_PATH==null}} (either because the TEST_KEYSTORE file does not 
exist and no sysprop was used to override it) then we fail fast with a useful 
error telling people to either:
** set the test sysprop
** ensure the expected file is in TEST_KEYSTORE
** add {{@SupressSSL}} to their tests.

> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



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

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

[jira] [Created] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

[Hoss Man (JIRA)]

Hoss Man created SOLR-8970:
--

 Summary: SSLTestConfig behaves really stupid if keystore can't be 
found
 Key: SOLR-8970
 URL: https://issues.apache.org/jira/browse/SOLR-8970
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
"trySslClientAuth") but it has a hardcoded assumption that the keystore file it 
can use (for both the keystore and the truststore) will exist at a fixed path 
in the solr install.

when this works, it works fine - but if end users subclass/reuse SolrTestCaseJ4 
in their own projects, they may do so in a way that prevents the SSLTestConfig 
keystore assumptions from being true, and yet they won't get any sort of clear 
error.




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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1073 - Still Failing

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestCoreDiscovery

Error Message:
ObjectTracker found 4 object(s) that were not released!!! [SolrCore, 
MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [SolrCore, MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor]
at __randomizedtesting.SeedInfo.seed([3BA95E80599A5A0B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestCoreDiscovery

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestCoreDiscovery: 
1) Thread[id=10722, name=searcherExecutor-4888-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)   
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestCoreDiscovery: 
   1) Thread[id=10722, name=searcherExecutor-4888-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([3BA95E80599A5A0B]:0)

Re: [JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 514 - Failure!

[Chris Hostetter]

http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/88965a0b

: Date: Mon, 11 Apr 2016 14:11:31 -0400
: From: Michael McCandless 
: Reply-To: dev@lucene.apache.org
: To: Policeman Jenkins Server 
: Cc: m...@apache.org, tomm...@apache.org,
: Varun Thacker ,
: Robert Muir , Lucene/Solr dev 
: Subject: Re: [JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build #
: 514 - Failure!
: 
: Is this saying that classification javadocs are angry?
: 
: Mike McCandless
: 
: http://blog.mikemccandless.com
: 
: On Mon, Apr 11, 2016 at 1:41 PM, Policeman Jenkins Server <
: jenk...@thetaphi.de> wrote:
: 
: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/514/
: > Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
: >
: > All tests passed
: >
: > Build Log:
: > [...truncated 53072 lines...]
: >   [javadoc] Generating Javadoc
: >   [javadoc] Javadoc execution
: >   [javadoc] Loading source files for package
: > org.apache.lucene.classification...
: >   [javadoc] Loading source files for package
: > org.apache.lucene.classification.document...
: >   [javadoc] Loading source files for package
: > org.apache.lucene.classification.utils...
: >   [javadoc] Constructing Javadoc information...
: >   [javadoc] javadoc: warning - Error reading file:
: > 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/docs/classification/../group/package-list
: >   [javadoc] Standard Doclet version 1.8.0_72
: >   [javadoc] Building tree for all the packages and classes...
: >   [javadoc] Building index for all the packages and classes...
: >   [javadoc] Building index for all classes...
: >   [javadoc] Generating
: > 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/docs/classification/help-doc.html...
: >   [javadoc] Note: Custom tags that were not seen:  @lucene.internal
: >   [javadoc] 1 warning
: >
: > BUILD FAILED
: > /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:740:
: > The following error occurred while executing this line:
: > /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:101:
: > The following error occurred while executing this line:
: > 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:138:
: > The following error occurred while executing this line:
: > 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:246:
: > The following error occurred while executing this line:
: > 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2187:
: > The following error occurred while executing this line:
: > 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/classification/build.xml:46:
: > The following error occurred while executing this line:
: > 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:78:
: > The following error occurred while executing this line:
: > 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2163:
: > Javadocs warnings were found!
: >
: > Total time: 88 minutes 41 seconds
: > Build step 'Invoke Ant' marked build as failure
: > Archiving artifacts
: > [WARNINGS] Skipping publisher since build result is FAILURE
: > Recording test results
: > Email was triggered for: Failure - Any
: > Sending email for trigger: Failure - Any
: >
: >
: 

-Hoss
http://www.lucidworks.com/

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

Re: Solrj API for Managed Resources

[Chris Hostetter]

https://people.apache.org/~hossman/#solr-user
Please Use "solr-user@lucene" Not "dev@lucene"

Your question is better suited for the solr-user@lucene mailing list ...
not the dev@lucene list.  The dev list is for discussing development of
the internals of Solr and the Lucene Java library ... it is *not* the 
appropriate place to ask questions about how to use Solr or the Lucene 
Java library when developing your own applications.  Please resend your 
message to the solr-user mailing list, where you are likely to get 
more/betterresponses since that list also has a larger number of 
subscribers.


: Date: Mon, 11 Apr 2016 15:59:18 -0700 (MST)
: From: srinivas raj 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: Solrj API for Managed Resources
: 
: Is there a solrj API to add synonyms or stop words using the Managed
: Resources API? I have to programmatically add them, what is the best way?
: 
: 
: 
: --
: View this message in context: 
http://lucene.472066.n3.nabble.com/Solrj-API-for-Managed-Resources-tp4269448.html
: Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
: 
: -
: To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: For additional commands, e-mail: dev-h...@lucene.apache.org
: 
: 

-Hoss
http://www.lucidworks.com/

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

[jira] [Updated] (SOLR-8929) Add an idea module for solr/server to enable launching start.jar

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-8929:
-
Attachment: SOLR-8929-bin-solr-run-configuration.patch

I understand why you want to introduce this new module, but I'm reluctant to do 
so, given that it's only to support run configurations (vs. source code).

bq. it's difficult to create a launch config to run Solr in the same way that 
the bin/solr script would

The attached patch creates a run configuration that launches bin/solr in 
foreground cloud mode.  Would this be an acceptable alternative?  If so, we 
could also add one for *nix standalone mode, as well as Windows versions.

> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Priority: Minor
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



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

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

Solrj API for Managed Resources

[srinivas raj]

Is there a solrj API to add synonyms or stop words using the Managed
Resources API? I have to programmatically add them, what is the best way?



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Solrj-API-for-Managed-Resources-tp4269448.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 134 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/134/

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

Error Message:
replicaCount expected:<0> but was:<1>

Stack Trace:
java.lang.AssertionError: replicaCount expected:<0> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([E581FC02124E1D5F:6DD5C3D8BCB270A7]: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.apache.solr.cloud.CollectionsAPIDistributedZkTest.testNoConfigSetExist(CollectionsAPIDistributedZkTest.java:601)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Updated] (SOLR-8208) DocTransformer executes sub-queries

[Mikhail Khludnev (JIRA)]

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

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

attaching a test with logParamsList and json assert

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Attachments: SOLR-8208.diff, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call them sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in =\[..\] ?
> I suppose we can allow to specify subquery parameter prefix:
> {code}
> ..=id,[subquery paramPrefix=subq1. 
> fromIndex=othercore],score,..={!term f=child_id 
> v=$subq1.row.id}=3=price&..
> {code}   
> * {{paramPrefix=subq1.}} shifts parameters for subquery: {{subq1.q}} turns to 
> {{q}} for subquery, {{subq1.rows}} to {{rows}}
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> * the itchiest one is to reference to document field from subquery 
> parameters, here I propose to use local param {{v}} and param deference 
> {{v=$param}} thus every document field implicitly introduces parameter for 
> subquery $\{paramPrefix\}row.$\{fieldName\}, thus above subquery is 
> q=child_id:, presumably we can drop "row." in the middle 
> (reducing to v=$subq1.id), until someone deal with {{rows}}, {{sort}} fields. 
> * \[subquery\], or \[query\], or ? 
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



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

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

[jira] [Commented] (SOLR-8950) Provide an option to "disable" a specified Solr collection

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-8950:


Another option may be implementing 
[SOLR-6399|https://issues.apache.org/jira/browse/SOLR-6399]

> Provide an option to "disable" a specified Solr collection
> --
>
> Key: SOLR-8950
> URL: https://issues.apache.org/jira/browse/SOLR-8950
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: 4.10.3, trunk
>Reporter: Hrishikesh Gadre
>
> Currently Solr does not provide facility to "disable" read/write requests for 
> a specified collection. This is essential for certain admin operations (e.g. 
> restore collection data from an earlier snapshot). Without this support, we 
> need to bring down the Solr cluster during the snapshot recovery. In case of 
> multi-tenant Solr cluster, it is not always feasible to bring down the Solr 
> service since it can affect the availability of other collections too.



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

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

[jira] [Updated] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated LUCENE-7188:
-
Fix Version/s: 6.1

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
> Fix For: 6.1
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, _9v_Lucene50_0.tim, 
> _9v_Lucene50_0.tip, _9w.fdt, _9w.fdx, _9w.fnm, _9w.nvd, _9w.nvm, _9w.si, 
> _9w_Lucene50_0.doc, _9w_Lucene50_0.pos, _9w_Lucene50_0.tim, 
> _9w_Lucene50_0.tip, _9x.fdt, _9x.fdx, _9x.fnm, _9x.nvd, _9x.nvm, _9x.si, 
> _9x_Lucene50_0.doc, _9x_Lucene50_0.pos, _9x_Lucene50_0.tim, 
> _9x_Lucene50_0.tip, _9y.fdt, _9y.fdx, _9y.fnm, _9y.nvd, _9y.nvm, _9y.si, 
> 

[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-7188:
--

I've also seen this exception/bug crop up when running chaos monkey tests.

David, you are correct.  LUCENE-5945 caused this bug by adding the exception 
without additional needed synchronization.  It can be fixed by either removing 
the exception or adding the additional synchronization.


> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, _9v_Lucene50_0.tim, 
> _9v_Lucene50_0.tip, _9w.fdt, _9w.fdx, _9w.fnm, _9w.nvd, _9w.nvm, _9w.si, 
> 

[JENKINS] Lucene-Solr-Tests-master - Build # 1072 - Still Failing

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([6CE2E3FC00E2A64B:7AD438179ED7B71]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:134)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy(ZkStateReaderTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12164 lines...]
   [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateReaderTest
   [junit4]   2> Creating dataDir: 

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_72) - Build # 398 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/398/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
ObjectTracker found 3 object(s) that were not released!!! [NRTCachingDirectory, 
NRTCachingDirectory, NRTCachingDirectory]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 3 object(s) that were not 
released!!! [NRTCachingDirectory, NRTCachingDirectory, NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([EA53F3A6E0853F14]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:256)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11597 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_EA53F3A6E0853F14-001/init-core-data-001
   [junit4]   2> 965587 INFO  
(TEST-TestReplicationHandler.doTestRepeater-seed#[EA53F3A6E0853F14]) [] 
o.a.s.SolrTestCaseJ4 ###Starting doTestRepeater
   [junit4]   2> 965587 INFO  
(TEST-TestReplicationHandler.doTestRepeater-seed#[EA53F3A6E0853F14]) [] 
o.a.s.SolrTestCaseJ4 Writing core.properties file to 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_EA53F3A6E0853F14-001/solr-instance-001/collection1
   [junit4]   2> 965590 INFO  
(TEST-TestReplicationHandler.doTestRepeater-seed#[EA53F3A6E0853F14]) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 965590 INFO  
(TEST-TestReplicationHandler.doTestRepeater-seed#[EA53F3A6E0853F14]) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@16ee715e{/solr,null,AVAILABLE}
   [junit4]   2> 965591 INFO  
(TEST-TestReplicationHandler.doTestRepeater-seed#[EA53F3A6E0853F14]) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@723729ab{HTTP/1.1,[http/1.1]}{127.0.0.1:38242}
   [junit4]   2> 965591 INFO  
(TEST-TestReplicationHandler.doTestRepeater-seed#[EA53F3A6E0853F14]) [] 
o.e.j.s.Server Started @967179ms
   [junit4]   2> 965591 INFO  
(TEST-TestReplicationHandler.doTestRepeater-seed#[EA53F3A6E0853F14]) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: 
{solr.data.dir=/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_EA53F3A6E0853F14-001/solr-instance-001/collection1/data,
 hostContext=/solr, hostPort=38242}
   [junit4]   2> 965591 INFO  

[jira] [Commented] (LUCENE-7155) Script addVersion.py does not detect the new naming convention for bugfix branches

[Ryan Ernst (JIRA)]

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

Ryan Ernst commented on LUCENE-7155:


+1 to the latest patch.

> Script addVersion.py does not detect the new naming convention for bugfix 
> branches
> --
>
> Key: LUCENE-7155
> URL: https://issues.apache.org/jira/browse/LUCENE-7155
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: -tools
>Affects Versions: 5.5, master, 6.0, 6.x
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.5, master
>
> Attachments: LUCENE-7155-improve.patch, LUCENE-7155-improve.patch, 
> LUCENE-7155.patch
>
>
> Spinoff from LUCENE-6938. Earlier we named release branches 
> {{lucene_solr_X_Y}} while now we name them {{branch_X_Y}}.



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

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

[jira] [Commented] (SOLR-8241) Evaluate W-TinyLfu cache

[Jeff Wartes (JIRA)]

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

Jeff Wartes commented on SOLR-8241:
---

Since Solr requires Java 8 as of 6.0, it seems like this patch could be applied 
pretty easily now?

> Evaluate W-TinyLfu cache
> 
>
> Key: SOLR-8241
> URL: https://issues.apache.org/jira/browse/SOLR-8241
> Project: Solr
>  Issue Type: Wish
>  Components: search
>Reporter: Ben Manes
>Priority: Minor
> Attachments: SOLR-8241.patch
>
>
> SOLR-2906 introduced an LFU cache and in-progress SOLR-3393 makes it O(1). 
> The discussions seem to indicate that the higher hit rate (vs LRU) is offset 
> by the slower performance of the implementation. An original goal appeared to 
> be to introduce ARC, a patented algorithm that uses ghost entries to retain 
> history information.
> My analysis of Window TinyLfu indicates that it may be a better option. It 
> uses a frequency sketch to compactly estimate an entry's popularity. It uses 
> LRU to capture recency and operate in O(1) time. When using available 
> academic traces the policy provides a near optimal hit rate regardless of the 
> workload.
> I'm getting ready to release the policy in Caffeine, which Solr already has a 
> dependency on. But, the code is fairly straightforward and a port into Solr's 
> caches instead is a pragmatic alternative. More interesting is what the 
> impact would be in Solr's workloads and feedback on the policy's design.
> https://github.com/ben-manes/caffeine/wiki/Efficiency



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

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

[jira] [Commented] (SOLR-3191) field exclusion from fl

[Ryan McKinley (JIRA)]

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

Ryan McKinley commented on SOLR-3191:
-

The failure for GeoJSONResponseWriter will most likely have to do with 'fields' 
vs 'okFields' -- that is, the fields we need to request from Lucene, and 
'okFields' the fields that need to be returned to the end user.

> a separate extension of ReturnFields?

ugg -- unless there is a really good reason, we should avoid this

> field exclusion from fl
> ---
>
> Key: SOLR-3191
> URL: https://issues.apache.org/jira/browse/SOLR-3191
> Project: Solr
>  Issue Type: Improvement
>Reporter: Luca Cavanna
>Priority: Minor
> Attachments: SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch, 
> SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch
>
>
> I think it would be useful to add a way to exclude field from the Solr 
> response. If I have for example 100 stored fields and I want to return all of 
> them but one, it would be handy to list just the field I want to exclude 
> instead of the 99 fields for inclusion through fl.



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

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

[jira] [Updated] (SOLR-8925) Add gatherNodes Streaming Expression to support breadth first traversals

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8925:
-
Description: 
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression above is evaluated as follows:

1) The inner search() expression is evaluated on the *articles* collection, 
emitting a Stream of Tuples with the author field populated.
2) The inner gatherNodes() expression reads the Tuples form the search() stream 
and traverses to the *friends* collection by performing a distributed join 
between articles.author and friends.user field.  It gathers the value from the 
*friend* field during the join.
3) The inner gatherNodes() expression then emits the *friend* Tuples. By 
default the gatherNodes function emits only the leaves which in this case are 
the *friend* tuples.
4) The outer gatherNodes() expression reads the *friend* Tuples and Traverses 
again in the "friends" collection, this time performing the join between 
*friend* Tuples  emitted in step 3. This collects the friend of friends.
5) The outer gatherNodes() expression emits the entire graph that was 
collected. This is controlled by the "scatter" parameter. In the example the 
*root* nodes are the authors, the *branches* are the author's friends and the 
*leaves* are the friend of friends.

This traversal is fully distributed and cross collection.

*Aggregations* are also supported during the traversal. This can be useful for 
making recommendations based on co-occurance counts: Sample syntax:
{code}
top(
  gatherNodes(baskets,
  search(baskets, q=“prodid:X”, fl=“basketid”, rows=“500”, 
sort=“random_7897987 asc”),
  walk =“basketid->basketid”,
  gather=“prodid”,
  fl=“prodid, price”,
  count(*),
  avg(price)),
  n=4,
  sort=“count(*) desc, avg(price) asc”)
{code}

In the expression above, the inner search() function searches the basket 
collection for 500 random basketId's that have the prodid X.

gatherNodes then traverses the basket collection and gathers all the prodid's 
for the selected basketIds.
It also aggregates the counts and average price for each productid collected. 
The count reflects the co-occurance count for each prodid gathered and prodid 
X. The outer *top* expression selects the top 4 prodid's emitted from 
gatherNodes, based the co-occurance count and avg price.

Like all streaming expressions the gatherNodes expression can be combined with 
other streaming expressions. For example the following expression uses a 
hashJoin to intersect the network of friends rooted to authors found with 
different queries:

{code}
hashInnerJoin(
  gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryA)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
   gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryB)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
  on=“friend”
 )
{code}






  


  was:
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}

Re: Lucene/Solr 5.5.1

[Anshum Gupta]

Thanks Ishan. I'll take a look.

On Mon, Apr 11, 2016 at 10:04 AM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Hi Anshum,
>
> I'd like someone to backport the following:
> SOLR-8838
> SOLR-8082
> SOLR-8865
>
> These are mentioned in the bug-fix section of 6.0, so I agree with Yonik
> that we should perhaps look at all of those changes.
> Thanks and regards,
> Ishan
>
>
> On Mon, Apr 11, 2016 at 9:55 PM, Yonik Seeley  wrote:
>
>> On Sun, Apr 10, 2016 at 12:59 PM, Anshum Gupta 
>> wrote:
>> > Hi,
>> >
>> > I would like to release 5.5.1, specially for to SOLR-8725.
>> >
>> > SOLR-8642 in 5.5 stops people from upgrading to 5.5 and a lot of users
>> have
>> > spoken about it on the mailing list and the JIRA.
>> >
>> > I would like to start the process towards the end of the coming week.
>>
>> At a minimum, we should prob look at the whole bug-fix section of 6.0
>>
>> -Yonik
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>


-- 
Anshum Gupta

Re: Lucene/Solr 5.5.1

[Anshum Gupta]

I agree and that is on my list of things to do for the release.

On Mon, Apr 11, 2016 at 9:25 AM, Yonik Seeley  wrote:

> On Sun, Apr 10, 2016 at 12:59 PM, Anshum Gupta 
> wrote:
> > Hi,
> >
> > I would like to release 5.5.1, specially for to SOLR-8725.
> >
> > SOLR-8642 in 5.5 stops people from upgrading to 5.5 and a lot of users
> have
> > spoken about it on the mailing list and the JIRA.
> >
> > I would like to start the process towards the end of the coming week.
>
> At a minimum, we should prob look at the whole bug-fix section of 6.0
>
> -Yonik
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Anshum Gupta

[jira] [Updated] (SOLR-8925) Add gatherNodes Streaming Expression to support breadth first traversals

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8925:
-
Description: 
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression above is evaluated as follows:

1) The inner search() expression is evaluated on the *articles* collection, 
emitting a Stream of Tuples with the author field populated.
2) The inner gatherNodes() expression reads the Tuples form the search() stream 
and traverses to the *friends* collection by performing a distributed join 
between articles.author and friends.user field.  It gathers the value from the 
*friend* field during the join.
3) The inner gatherNodes() expression then emits the *friend* Tuples. By 
default the gatherNodes function emits only the leaves which in this case are 
the *friend* tuples.
4) The outer gatherNodes() expression reads the *friend* Tuples and Traverses 
again in the "friends" collection, this time performing the join between 
*friend* Tuples  emitted in step 3. This collects the friend of friends.
5) The outer gatherNodes() expression emits the entire graph that was 
collected. This is controlled by the "scatter" parameter. In the example the 
*root* nodes are the authors, the *branches* are the author's friends and the 
*leaves* are the friend of friends.

This traversal is fully distributed and cross collection.

*Aggregations* are also supported during the traversal. This can be useful for 
making recommendations based on co-occurance counts: Sample syntax:
{code}
top(
  gatherNodes(baskets,
  search(baskets, q=“prodid:X”, fl=“basketid”, rows=“500”, 
sort=“random_7897987 asc”),
  walk =“basketid->basketid”,
  gather=“prodid”,
  fl=“prodid, price”,
  count(*),
  avg(price)),
  n=4,
  sort=“count(*) desc, avg(price) asc”)
{code}

In the expression above, the inner search() function searches the basket 
collection for 500 random basketId's that have the prodid X.

gatherNodes then traverses the basket collection and gathers all the prodid's 
for the selected basketIds.
It aggregates the counts and average price for each productid collected. The 
count reflects the co-occurance count for each prodid gathered and prodid X. 
The outer *top* expression selects the top 4 prodid's emitted from gatherNodes, 
based the co-occurance count and avg price.

Like all streaming expressions the gatherNodes expression can be combined with 
other streaming expressions. For example the following expression uses a 
hashJoin to intersect the network of friends rooted to authors found with 
different queries:

{code}
hashInnerJoin(
  gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryA)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
   gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryB)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
  on=“friend”
 )
{code}






  


  was:
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}

[jira] [Updated] (SOLR-8925) Add gatherNodes Streaming Expression to support breadth first traversals

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8925:
-
Description: 
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression above is evaluated as follows:

1) The inner search() expression is evaluated on the *articles* collection, 
emitting a Stream of Tuples with the author field populated.
2) The inner gatherNodes() expression reads the Tuples form the search() stream 
and traverses to the *friends* collection by performing a distributed join 
between articles.author and friends.user field.  It gathers the value from the 
*friend* field during the join.
3) The inner gatherNodes() expression then emits the *friend* Tuples. By 
default the gatherNodes function emits only the leaves which in this case are 
the *friend* tuples.
4) The outer gatherNodes() expression reads the *friend* Tuples and Traverses 
again in the "friends" collection, this time performing the join between 
*friend* Tuples  emitted in step 3. This collects the friend of friends.
5) The outer gatherNodes() expression emits the entire graph that was 
collected. This is controlled by the "scatter" parameter. In the example the 
*root* nodes are the authors, the *branches* are the author's friends and the 
*leaves* are the friend of friends.

This traversal is fully distributed and cross collection.

*Aggregations* are also supported during the traversal. This can be useful for 
making recommendations based on co-occurance counts: Sample syntax:
{code}
top(
  gatherNodes(baskets,
  search(baskets, q=“prodid:X”, fl=“basketid”, rows=“500”, 
sort=“random_7897987 asc”),
  walk =“basketid->basketid”,
  gather=“prodid”,
  fl=“prodid, price”,
  count(*),
  avg(price)),
  n=4,
  sort=“count(*) desc, avg(price) asc”)
{code}

In the expression above, the inner search() function searches the basket 
collection for 500 random basketId's that have the prodid X.

gatherNodes then traverses the basket collection and gathers all the prodid's 
for the selected basketIds.
It aggregates the counts and average price for each productid collected. The 
count reflects the co-occurance count for each prodid gathered and prodid X. 
The outer *top* expression selects the top 4 prodid's emitted from gatherNodes, 
based the count and avg price.

Like all streaming expressions the gatherNodes expression can be combined with 
other streaming expressions. For example the following expression uses a 
hashJoin to intersect the network of friends rooted to authors found with 
different queries:

{code}
hashInnerJoin(
  gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryA)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
   gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryB)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
  on=“friend”
 )
{code}






  


  was:
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression 

[jira] [Updated] (SOLR-8925) Add gatherNodes Streaming Expression to support breadth first traversals

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8925:
-
Description: 
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression above is evaluated as follows:

1) The inner search() expression is evaluated on the *articles* collection, 
emitting a Stream of Tuples with the author field populated.
2) The inner gatherNodes() expression reads the Tuples form the search() stream 
and traverses to the *friends* collection by performing a distributed join 
between articles.author and friends.user field.  It gathers the value from the 
*friend* field during the join.
3) The inner gatherNodes() expression then emits the *friend* Tuples. By 
default the gatherNodes function emits only the leaves which in this case are 
the *friend* tuples.
4) The outer gatherNodes() expression reads the *friend* Tuples and Traverses 
again in the "friends" collection, this time performing the join between 
*friend* Tuples  emitted in step 3. This collects the friend of friends.
5) The outer gatherNodes() expression emits the entire graph that was 
collected. This is controlled by the "scatter" parameter. In the example the 
*root* nodes are the authors, the *branches* are the author's friends and the 
*leaves* are the friend of friends.

This traversal is fully distributed and cross collection.

*Aggregations* are also supported during the traversal. This can be useful for 
making recommendations based on co-occurance counts: Sample syntax:
{code}
top(
  gatherNodes(baskets,
   search(baskets, q=“prodid:X”, fl=“basketid”, rows=“500”, 
sort=“random_7897987 asc”),
   walk =“basketid->basketid”,
   gather=“prodid”,
   fl=“prodid, price”,
   count(*),
   avg(price)),
  n=4,
  sort=“count(*) desc, avg(price) asc”)
{code}

In the expression above, the inner search() function searches the basket 
collection for 500 random basketId's that have the prodid X.

gatherNodes then traverses the basket collection and gathers all the prodid's 
for the selected basketIds.
It aggregates the counts and average price for each productid collected. The 
count reflects the co-occurance count for each product and prodid X. The outer 
*top* expression selects the top 4 prodid's emitted from gatherNodes, based the 
count and avg price.

Like all streaming expressions the gatherNodes expression can be combined with 
other streaming expressions. For example the following expression uses a 
hashJoin to intersect the network of friends rooted to authors found with 
different queries:

{code}
hashInnerJoin(
  gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryA)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
   gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryB)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
  on=“friend”
 )
{code}






  


  was:
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression 

[jira] [Updated] (SOLR-8925) Add gatherNodes Streaming Expression to support breadth first traversals

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8925:
-
Description: 
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression above is evaluated as follows:

1) The inner search() expression is evaluated on the *articles* collection, 
emitting a Stream of Tuples with the author field populated.
2) The inner gatherNodes() expression reads the Tuples form the search() stream 
and traverses to the *friends* collection by performing a distributed join 
between articles.author and friends.user field.  It gathers the value from the 
*friend* field during the join.
3) The inner gatherNodes() expression then emits the *friend* Tuples. By 
default the gatherNodes function emits only the leaves which in this case are 
the *friend* tuples.
4) The outer gatherNodes() expression reads the *friend* Tuples and Traverses 
again in the "friends" collection, this time performing the join between 
*friend* Tuples  emitted in step 3. This collects the friend of friends.
5) The outer gatherNodes() expression emits the entire graph that was 
collected. This is controlled by the "scatter" parameter. In the example the 
*root* nodes are the authors, the *branches* are the author's friends and the 
*leaves* are the friend of friends.

This traversal is fully distributed and cross collection.

*Aggregations* are also supported during the traversal. This can be useful for 
making recommendations based on co-occurance counts: Sample syntax:
{code}
top(
  gatherNodes(baskets,
  search(baskets, q=“prodid:X”, fl=“basketid”, rows=“500”, 
sort=“random_7897987 asc”),
  walk =“basketid->basketid”,
  gather=“prodid”,
  fl=“prodid, price”,
  count(*),
  avg(price)),
  n=4,
  sort=“count(*) desc, avg(price) asc”)
{code}

In the expression above, the inner search() function searches the basket 
collection for 500 random basketId's that have the prodid X.

gatherNodes then traverses the basket collection and gathers all the prodid's 
for the selected basketIds.
It aggregates the counts and average price for each productid collected. The 
count reflects the co-occurance count for each product and prodid X. The outer 
*top* expression selects the top 4 prodid's emitted from gatherNodes, based the 
count and avg price.

Like all streaming expressions the gatherNodes expression can be combined with 
other streaming expressions. For example the following expression uses a 
hashJoin to intersect the network of friends rooted to authors found with 
different queries:

{code}
hashInnerJoin(
  gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryA)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
   gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryB)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
  on=“friend”
 )
{code}






  


  was:
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression above is 

[jira] [Updated] (SOLR-8925) Add gatherNodes Streaming Expression to support breadth first traversals

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8925:
-
Description: 
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression above is evaluated as follows:

1) The inner search() expression is evaluated on the *articles* collection, 
emitting a Stream of Tuples with the author field populated.
2) The inner gatherNodes() expression reads the Tuples form the search() stream 
and traverses to the *friends* collection by performing a distributed join 
between articles.author and friends.user field.  It gathers the value from the 
*friend* field during the join.
3) The inner gatherNodes() expression then emits the *friend* Tuples. By 
default the gatherNodes function emits only the leaves which in this case are 
the *friend* tuples.
4) The outer gatherNodes() expression reads the *friend* Tuples and Traverses 
again in the "friends" collection, this time performing the join between 
*friend* Tuples  emitted in step 3. This collects the friend of friends.
5) The outer gatherNodes() expression emits the entire graph that was 
collected. This is controlled by the "scatter" parameter. In the example the 
*root* nodes are the authors, the *branches* are the author's friends and the 
*leaves* are the friend of friends.

This traversal is fully distributed and cross collection.

Aggregations are also supported during the traversal. This can be useful for 
making recommendations based on co-occurance counts: Sample syntax:
{code}
top(
  gatherNodes(baskets,
   search(baskets, q=“prodid:X”, fl=“basketid”, rows=“500”, 
sort=“random_7897987 asc”),
   walk =“basketid->basketid”,
   gather=“prodid”,
   fl=“prodid, price”,
   count(*),
   avg(price)),
  n=4,
  sort=“count(*) desc, avg(price) asc”)
{code}

In the expression above, the inner search() function searches the basket 
collection for 500 random basketId's that have the prodid X.

gatherNodes then traverses the basket collection and gathers all the prodid's 
for the selected basketIds.
It aggregates the counts and average price for each productid collected. The 
count reflects the co-occurance count for each product and prodid X. The outer 
*top* expression selects the top 4 prodid's emitted from gatherNodes, based the 
count and avg price.

Like all streaming expressions the gatherNodes expression can be combined with 
other streaming expressions. For example the following expression uses a 
hashJoin to intersect the network of friends rooted to authors found with 
different queries:

{code}
hashInnerJoin(
  gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryA)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
   gatherNodes(friends,
  gatherNodes(friends,
  search(articles, 
q=“body:(queryB)”, fl=“author”),
  walk ="author->user”,
  gather="friend"),
  walk=“friend->user”,
  gather="friend",
  scatter=“branches, leaves”),
  on=“friend”
 )
{code}






  


  was:
The gatherNodes Streaming Expression is a flexible general purpose breadth 
first graph traversal. It uses the same parallel join under the covers as 
(SOLR-) but is much more generalized and can be used for a wide range of 
use cases.

Sample syntax:

{code}

 gatherNodes(friends,
 gatherNodes(friends,
 search(articles, q=“body:(queryA)”, fl=“author”),
 walk ="author->user”,
 gather="friend"),
 walk=“friend->user”,
 gather="friend",
 scatter=“roots, branches, leaves”)
{code}


The expression 

[jira] [Commented] (LUCENE-5325) Move ValueSource and FunctionValues under core/

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-5325:
--

bq. One of the issues I have with ValueSource is that it's inherently 
type-unsafe - you have no way of saying what sort of value you want from a 
ValueSource input.

This comment reminded me of a discussion I remember having a long time ago that 
i started typing up a summary of in case it inspires folks, but then realized I 
already filed as SOLR-6575 the last time someone mentioned something that 
reminded me of it.

Might be some helpful ideas there if folks are looking to revamp & improve the 
type specificity of the ValueSource APIs


> Move ValueSource and FunctionValues under core/
> ---
>
> Key: LUCENE-5325
> URL: https://issues.apache.org/jira/browse/LUCENE-5325
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Shai Erera
>
> Spinoff from LUCENE-5298: ValueSource and FunctionValues are abstract APIs 
> which exist under the queries/ module. That causes any module which wants to 
> depend on these APIs (but not necessarily on any of their actual 
> implementations!), to depend on the queries/ module. If we move these APIs 
> under core/, we can eliminate these dependencies and add some mock impls for 
> testing purposes.
> Quoting Robert from LUCENE-5298:
> {quote}
> we should eliminate the suggest/ dependencies on expressions and queries, the 
> expressions/ on queries, the grouping/ dependency on queries, the spatial/ 
> dependency on queries, its a mess.
> {quote}
> To add to that list, facet/ should not depend on queries too.



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

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

[jira] [Commented] (SOLR-6575) ValueSources/FunctionValues should be able to (dynamically) indicate their prefered data type (propogating up)

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-6575:


I started writting this as a side comment in LUCENE-5325, before i remembered 
this issue already existed - so i'm posting it here and then i'll cross link...



Currently...

* ValueSource (via FunctionValues) expose various type specific accessors 
(boolVal, byteVal, doubleVal, floatVal, strVal, etc...) which can be used by 
callers who care about recieving a specific type -- and in which case the 
ValueSource is expected to "do it's best" to return whatever info it models as 
best it can in that type (typically a simple cast). 
* in practice, almost every "ValueSource wrapper" i can think of basically 
ignores the "requested type" when it's FunctionValues are used, and typically 
just uses doubleVal from the wrapped ValueSource/FunctionValues, and then does 
i's own simple cast. (see DualFloatFunction)
* one special case FunctionValues method is "objectVal" in which case the 
FunctionValues/ValueSource gets to make it's own decision about the type of 
object to "pass back" based on what makes the most sense given the source of 
the underlying ValueSource.  (ex: the DocValues type for fields, int for 
NumDocsValueSource, etc..)

Ideally...

* there should be a way to pass the "native typing" of a ValueSource *up* the 
stack, and a way to pass "type preference" down the stack.
* If you wrap a "math function" around 2 arbitrary ValueSources, but you don't 
have a preference about the specific type of the results (ex: a solr user has 
asked for {{product(fieldA,fieldB)}} -- or someone has created a similar 
looking Expression object in the java API) the resulting math operations done 
at the FunctionValues level should look at the "native typing" nformation 
"passed up" from the wrapped ValueSources to decide what data types to use, and 
what to return by default from things like the objectVal method, and what 
"native typing" to in turn pass up to it's own caller
** example: if you wrap 2 IntDocValues field ValueSource in a 
MathMultiplyValueSource maybe the "native result" should be a ValueSource that 
defaults to reutrning LongValues 
* If callers want to force the result to be an explict type - they should still 
be able to do that -- either themselves, or based on the choice of method they 
call (ie: the current FunctionValues methods like intVal, floatVal, etc...) w/o 
that preference automatically propogating down
** example: calling floatVal on a MathMultiplyValueSource that wraps 2 ints 
should be akin to: {{long result = intval1 * intval2; return (float) result;}} 
not {{return ((float)intval1) * ((float)intval2)}}
* we should have ValueSource wrappers that can act as "numeric casts" for folks 
who explicitly want to inject a type preference at arbitrary places in the 
hierarchy.
** example: if you prefer to use floating point multiplication on two 
ValueSources, regardless of what "native type" of those ValueSources are, you 
can wrap each of them in a "CastAsFloatValueSource" and then wrap all of those 
in your MathMultiplyValueSource.



There's probably a great way to accomplish much of this very naturally if we 
start moving towards a more type save ValueSource API utilizing generics better 
(allthough i'm not really sure how it we want to keep optimizing for primitive 
types like int/float/long/double instead Integer/Float/Long/Double) but as a 
straw man to try and try and clarify what i'm talking about...

Imagine adding the following to the existing ValueSource APIs..

* imagine if we add a {{Class getNativeClassValue()}} method to ValueSource, 
documented as always returning the same Class as you would get from any call to 
{{FunctionValues.objectVal(int).getClass()}} when using this ValueSource 
directly
* for Math based wrapper ValueSources, the type info from the 
getNativeClassValue() methods of the ValueSources they wrap sould be used to 
decide what FunctionValues impls to return (ie: MathMultiplyValueSource could 
do check the getNativeClassValue() of each VS it wrapped to find the least 
common denominator in the types to decide when to use something like 
MultiplyLongValueSource, or MultipleDoubleValueSource)
* new classes like CastFloatValueSource classes would be ValueSource wrappers 
that completely ignore the getNativeClassValue() of the VS they wrap. They 
would instead implement getNativeClassValue to return a constant Class (ex: 
Float), and would use a FunctionValues impl whose objectVal (and other methods) 
would just call the method that matches the cast they are suppose to do on the 
class they wrap -- ie: {code}Object objectVal(int doc) { return new 
Float(floatVal(doc)); }
int intVal(int doc) { return (int) floatVal(int doc); }
float floatVal(int doc) { return inner.floatVal(int doc); }
...{code}


> ValueSources/FunctionValues should be 

[jira] [Updated] (SOLR-8925) Add gatherNodes Streaming Expression to support breadth first traversals

[Joel Bernstein (JIRA)]

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

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

First patch also contains support for aggregations on the nodes during the 
traversal. Needs test cases.

> Add gatherNodes Streaming Expression to support breadth first traversals
> 
>
> Key: SOLR-8925
> URL: https://issues.apache.org/jira/browse/SOLR-8925
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.1
>
> Attachments: SOLR-8925.patch
>
>
> The gatherNodes Streaming Expression is a flexible general purpose breadth 
> first graph traversal. It uses the same parallel join under the covers as 
> (SOLR-) but is much more generalized and can be used for a wide range of 
> use cases.
> Sample syntax:
> {code}
>  gatherNodes(friends,
>  gatherNodes(friends,
>  search(articles, q=“body:(queryA)”, fl=“author”),
>  walk ="author->user”,
>  gather="friend"),
>  walk=“friend->user”,
>  gather="friend",
>  scatter=“roots, branches, leaves”)
> {code}
> The expression above is evaluated as follows:
> 1) The inner search() expression is evaluated on the *articles* collection, 
> emitting a Stream of Tuples with the author field populated.
> 2) The inner gatherNodes() expression reads the Tuples form the search() 
> stream and traverses to the *friends* collection by performing a distributed 
> join between articles.author and friends.user field.  It gathers the value 
> from the *friend* field during the join.
> 3) The inner gatherNodes() expression then emits the *friend* Tuples. By 
> default the gatherNodes function emits only the leaves which in this case are 
> the *friend* tuples.
> 4) The outer gatherNodes() expression reads the *friend* Tuples and Traverses 
> again in the "friends" collection, this time performing the join between 
> *friend* Tuples  emitted in step 3. This collects the friend of friends.
> 5) The outer gatherNodes() expression emits the entire graph that was 
> collected. This is controlled by the "scatter" parameter. In the example the 
> *root* nodes are the authors, the *branches* are the author's friends and the 
> *leaves* are the friend of friends.
> This traversal is fully distributed and cross collection.
> Like all streaming expressions the gather nodes expression can be combined 
> with other streaming expressions. For example the following expression uses a 
> hashJoin to intersect the network of friends rooted to authors found with 
> different queries:
> {code}
> hashInnerJoin(
>   gatherNodes(friends,
>   gatherNodes(friends,
>   search(articles, 
> q=“body:(queryA)”, fl=“author”),
>   walk ="author->user”,
>   gather="friend"),
>   walk=“friend->user”,
>   gather="friend",
>   scatter=“branches, leaves”),
>gatherNodes(friends,
>   gatherNodes(friends,
>   search(articles, 
> q=“body:(queryB)”, fl=“author”),
>   walk ="author->user”,
>   gather="friend"),
>   walk=“friend->user”,
>   gather="friend",
>   scatter=“branches, leaves”),
>   on=“friend”
>  )
> {code}
>   



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

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 461 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/461/

No tests ran.

Build Log:
[...truncated 40723 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (10.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 28.6 MB in 0.04 sec (700.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 62.9 MB in 0.06 sec (984.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 73.4 MB in 0.18 sec (413.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5989 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5989 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 219 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (16.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 37.6 MB in 0.53 sec (71.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 131.8 MB in 1.57 sec (83.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 140.3 MB in 1.44 sec (97.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]  

Re: Guidance needed

[David Smiley]

Welcome!  Thanks for wanting to contribute.  Usually people contribute out
of necessity to improve or fix something for a real project.  That helps
focus one's self on something and establish a goal.  Since that isn't the
case for you, I suggest looking through our JIRA issues tagged "newdev":
https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20text%20~%20newdev
Or perhaps search for "gsoc" (which stands for Google Summer of Code).

~ David

On Mon, Apr 11, 2016 at 3:00 PM gor joseph  wrote:

> Good Morning ,
>
> I am a young engineer looking to join and contribute to the
> project .However , I got stuck on the overwhelming docs and thousands of
> lines of code .
>  can anyone please give me advice on how to understand the project and
> contribute effectively ,?
>
> Thanks
>
> Sincerely ,
> Joseph.
> LinkedIn : https://fr.linkedin.com/in/josephgor
> Mobile : +33 630733572
> Skype :gor.jos...@outlook.com
> E-mail :gor.jos...@outlook.com
>
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Guidance needed

[gor joseph]

Good Morning ,




I am a young engineer looking to join and contribute to the project .However , 
I got stuck on the overwhelming docs and thousands of lines of code .

 can anyone please give me advice on how to understand the project and 
contribute effectively ,?




Thanks 






Sincerely ,
Joseph.
LinkedIn : https://fr.linkedin.com/in/josephgor
Mobile : +33 630733572
Skype :gor.jos...@outlook.com
E-mail :gor.jos...@outlook.com

[jira] [Commented] (LUCENE-5325) Move ValueSource and FunctionValues under core/

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-5325:
--

bq. Like the multi-value aspect, which is in turn only used by a small piece of 
Solr.

Indeed, multi-value VS needs to change!

> Move ValueSource and FunctionValues under core/
> ---
>
> Key: LUCENE-5325
> URL: https://issues.apache.org/jira/browse/LUCENE-5325
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Shai Erera
>
> Spinoff from LUCENE-5298: ValueSource and FunctionValues are abstract APIs 
> which exist under the queries/ module. That causes any module which wants to 
> depend on these APIs (but not necessarily on any of their actual 
> implementations!), to depend on the queries/ module. If we move these APIs 
> under core/, we can eliminate these dependencies and add some mock impls for 
> testing purposes.
> Quoting Robert from LUCENE-5298:
> {quote}
> we should eliminate the suggest/ dependencies on expressions and queries, the 
> expressions/ on queries, the grouping/ dependency on queries, the spatial/ 
> dependency on queries, its a mess.
> {quote}
> To add to that list, facet/ should not depend on queries too.



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

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

[jira] [Commented] (LUCENE-5325) Move ValueSource and FunctionValues under core/

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-5325:
--

Definitely sounds great.  I know what you mean by this having a lot of warts.  
Like the multi-value aspect, which is in turn only used by a small piece of 
Solr.

> Move ValueSource and FunctionValues under core/
> ---
>
> Key: LUCENE-5325
> URL: https://issues.apache.org/jira/browse/LUCENE-5325
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Shai Erera
>
> Spinoff from LUCENE-5298: ValueSource and FunctionValues are abstract APIs 
> which exist under the queries/ module. That causes any module which wants to 
> depend on these APIs (but not necessarily on any of their actual 
> implementations!), to depend on the queries/ module. If we move these APIs 
> under core/, we can eliminate these dependencies and add some mock impls for 
> testing purposes.
> Quoting Robert from LUCENE-5298:
> {quote}
> we should eliminate the suggest/ dependencies on expressions and queries, the 
> expressions/ on queries, the grouping/ dependency on queries, the spatial/ 
> dependency on queries, its a mess.
> {quote}
> To add to that list, facet/ should not depend on queries too.



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

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

Re: Lucene/Solr 5.5.1

[David Smiley]

On Mon, Apr 11, 2016 at 2:15 PM Yonik Seeley  wrote:

> FWIW I backported to the 5x branch (and then to 55 branch from there)
> given that we could have a 5.6 release in the future.
>

Good; I think we should *always* do that when back-porting.  Not doing it
could really bite us by accident.
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (LUCENE-5325) Move ValueSource and FunctionValues under core/

[Ryan Ernst (JIRA)]

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

Ryan Ernst commented on LUCENE-5325:


[~romseygeek] sounds like an interesting idea, a prototype patch sounds good.

> Move ValueSource and FunctionValues under core/
> ---
>
> Key: LUCENE-5325
> URL: https://issues.apache.org/jira/browse/LUCENE-5325
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Shai Erera
>
> Spinoff from LUCENE-5298: ValueSource and FunctionValues are abstract APIs 
> which exist under the queries/ module. That causes any module which wants to 
> depend on these APIs (but not necessarily on any of their actual 
> implementations!), to depend on the queries/ module. If we move these APIs 
> under core/, we can eliminate these dependencies and add some mock impls for 
> testing purposes.
> Quoting Robert from LUCENE-5298:
> {quote}
> we should eliminate the suggest/ dependencies on expressions and queries, the 
> expressions/ on queries, the grouping/ dependency on queries, the spatial/ 
> dependency on queries, its a mess.
> {quote}
> To add to that list, facet/ should not depend on queries too.



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

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

Re: Lucene/Solr 5.5.1

[Yonik Seeley]

I just backported SOLR-8155... may do more when I get time, but taxes
and other stuff are waiting for me right now.
FWIW I backported to the 5x branch (and then to 55 branch from there)
given that we could have a 5.6 release in the future.

-Yonik


On Mon, Apr 11, 2016 at 1:04 PM, Ishan Chattopadhyaya
 wrote:
> Hi Anshum,
>
> I'd like someone to backport the following:
> SOLR-8838
> SOLR-8082
> SOLR-8865
>
> These are mentioned in the bug-fix section of 6.0, so I agree with Yonik
> that we should perhaps look at all of those changes.
> Thanks and regards,
> Ishan
>
>
> On Mon, Apr 11, 2016 at 9:55 PM, Yonik Seeley  wrote:
>>
>> On Sun, Apr 10, 2016 at 12:59 PM, Anshum Gupta 
>> wrote:
>> > Hi,
>> >
>> > I would like to release 5.5.1, specially for to SOLR-8725.
>> >
>> > SOLR-8642 in 5.5 stops people from upgrading to 5.5 and a lot of users
>> > have
>> > spoken about it on the mailing list and the JIRA.
>> >
>> > I would like to start the process towards the end of the coming week.
>>
>> At a minimum, we should prob look at the whole bug-fix section of 6.0
>>
>> -Yonik
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[jira] [Updated] (SOLR-8155) json.facet - prefix parameter doesn't work properly

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-8155:
---
Fix Version/s: 5.5.1
   5.6

> json.facet - prefix parameter doesn't work properly
> ---
>
> Key: SOLR-8155
> URL: https://issues.apache.org/jira/browse/SOLR-8155
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.3
>Reporter: Yosi Nesher
>Assignee: Yonik Seeley
> Fix For: 6.0, 5.5.1, 5.6
>
> Attachments: SOLR-8155.patch, SOLR-8155.patch
>
>
> When using prefix in nested facets, not all values are found.
> In the following query, I use facet with prefix in both old way (facet.field) 
> and new way (json.facet).
> In old way, I get 5 values. In new way I get only 3.
> This is the field definition in the schema:
>  required="false" multiValued="true" />
> When I add to the schema docValues="true" the issue is solved.
> Query:
> http://localhost:8983/solr/mycore/select?q=*%3A*=0=json=true=true=topics_f=2={trendFieldFacet:{type:terms,%20field:topics_f,%20%20prefix:%222%22%20}}
> Response:
> {
>   "responseHeader": {
> "status": 0,
> "QTime": 0,
> "params": {
>   "q": "*:*",
>   "json.facet": "{trendFieldFacet:{type:terms, field:topics_f,  
> prefix:\"2\" }}",
>   "facet.field": "topics_f",
>   "indent": "true",
>   "facet.prefix": "2",
>   "rows": "0",
>   "wt": "json",
>   "facet": "true",
>   "_": "1444566142012"
> }
>   },
>   "response": {
> "numFound": 17,
> "start": 0,
> "docs": []
>   },
>   "facet_counts": {
> "facet_queries": {},
> "facet_fields": {
>   "topics_f": [
> "2/device/iphone",
> 4,
> "2/device/samsung",
> 4,
> "2/city/london",
> 1,
> "2/city/rome",
> 1,
> "2/device/other",
> 1
>   ]
> },
> "facet_dates": {},
> "facet_ranges": {},
> "facet_intervals": {},
> "facet_heatmaps": {}
>   },
>   "facets": {
> "count": 17,
> "trendFieldFacet": {
>   "buckets": [
> {
>   "val": "2/device/iphone",
>   "count": 4
> },
> {
>   "val": "2/device/samsung",
>   "count": 4
> },
> {
>   "val": "2/device/other",
>   "count": 1
> }
>   ]
> }
>   }
> }



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

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

Re: [JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 514 - Failure!

[Michael McCandless]

Is this saying that classification javadocs are angry?

Mike McCandless

http://blog.mikemccandless.com

On Mon, Apr 11, 2016 at 1:41 PM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/514/
> Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
>
> All tests passed
>
> Build Log:
> [...truncated 53072 lines...]
>   [javadoc] Generating Javadoc
>   [javadoc] Javadoc execution
>   [javadoc] Loading source files for package
> org.apache.lucene.classification...
>   [javadoc] Loading source files for package
> org.apache.lucene.classification.document...
>   [javadoc] Loading source files for package
> org.apache.lucene.classification.utils...
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: warning - Error reading file:
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/docs/classification/../group/package-list
>   [javadoc] Standard Doclet version 1.8.0_72
>   [javadoc] Building tree for all the packages and classes...
>   [javadoc] Building index for all the packages and classes...
>   [javadoc] Building index for all classes...
>   [javadoc] Generating
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/docs/classification/help-doc.html...
>   [javadoc] Note: Custom tags that were not seen:  @lucene.internal
>   [javadoc] 1 warning
>
> BUILD FAILED
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:740:
> The following error occurred while executing this line:
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:101:
> The following error occurred while executing this line:
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:138:
> The following error occurred while executing this line:
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:246:
> The following error occurred while executing this line:
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2187:
> The following error occurred while executing this line:
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/classification/build.xml:46:
> The following error occurred while executing this line:
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:78:
> The following error occurred while executing this line:
> /export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2163:
> Javadocs warnings were found!
>
> Total time: 88 minutes 41 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> [WARNINGS] Skipping publisher since build result is FAILURE
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
>

[jira] [Commented] (SOLR-8155) json.facet - prefix parameter doesn't work properly

[ASF subversion and git services (JIRA)]

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

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

Commit c3446734a2b6dccd8092f5672651779223076dac in lucene-solr's branch 
refs/heads/branch_5_5 from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c344673 ]

SOLR-8155: fix UnInvertedField.collectDocsGeneric, used for facet.prefix or 
non-count sorting


> json.facet - prefix parameter doesn't work properly
> ---
>
> Key: SOLR-8155
> URL: https://issues.apache.org/jira/browse/SOLR-8155
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.3
>Reporter: Yosi Nesher
>Assignee: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8155.patch, SOLR-8155.patch
>
>
> When using prefix in nested facets, not all values are found.
> In the following query, I use facet with prefix in both old way (facet.field) 
> and new way (json.facet).
> In old way, I get 5 values. In new way I get only 3.
> This is the field definition in the schema:
>  required="false" multiValued="true" />
> When I add to the schema docValues="true" the issue is solved.
> Query:
> http://localhost:8983/solr/mycore/select?q=*%3A*=0=json=true=true=topics_f=2={trendFieldFacet:{type:terms,%20field:topics_f,%20%20prefix:%222%22%20}}
> Response:
> {
>   "responseHeader": {
> "status": 0,
> "QTime": 0,
> "params": {
>   "q": "*:*",
>   "json.facet": "{trendFieldFacet:{type:terms, field:topics_f,  
> prefix:\"2\" }}",
>   "facet.field": "topics_f",
>   "indent": "true",
>   "facet.prefix": "2",
>   "rows": "0",
>   "wt": "json",
>   "facet": "true",
>   "_": "1444566142012"
> }
>   },
>   "response": {
> "numFound": 17,
> "start": 0,
> "docs": []
>   },
>   "facet_counts": {
> "facet_queries": {},
> "facet_fields": {
>   "topics_f": [
> "2/device/iphone",
> 4,
> "2/device/samsung",
> 4,
> "2/city/london",
> 1,
> "2/city/rome",
> 1,
> "2/device/other",
> 1
>   ]
> },
> "facet_dates": {},
> "facet_ranges": {},
> "facet_intervals": {},
> "facet_heatmaps": {}
>   },
>   "facets": {
> "count": 17,
> "trendFieldFacet": {
>   "buckets": [
> {
>   "val": "2/device/iphone",
>   "count": 4
> },
> {
>   "val": "2/device/samsung",
>   "count": 4
> },
> {
>   "val": "2/device/other",
>   "count": 1
> }
>   ]
> }
>   }
> }



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

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

[jira] [Commented] (SOLR-8155) json.facet - prefix parameter doesn't work properly

[ASF subversion and git services (JIRA)]

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

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

Commit 0073ba9700d5df7b00d77a5d5dd831316f138042 in lucene-solr's branch 
refs/heads/branch_5x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0073ba9 ]

SOLR-8155: fix UnInvertedField.collectDocsGeneric, used for facet.prefix or 
non-count sorting


> json.facet - prefix parameter doesn't work properly
> ---
>
> Key: SOLR-8155
> URL: https://issues.apache.org/jira/browse/SOLR-8155
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.3
>Reporter: Yosi Nesher
>Assignee: Yonik Seeley
> Fix For: 6.0
>
> Attachments: SOLR-8155.patch, SOLR-8155.patch
>
>
> When using prefix in nested facets, not all values are found.
> In the following query, I use facet with prefix in both old way (facet.field) 
> and new way (json.facet).
> In old way, I get 5 values. In new way I get only 3.
> This is the field definition in the schema:
>  required="false" multiValued="true" />
> When I add to the schema docValues="true" the issue is solved.
> Query:
> http://localhost:8983/solr/mycore/select?q=*%3A*=0=json=true=true=topics_f=2={trendFieldFacet:{type:terms,%20field:topics_f,%20%20prefix:%222%22%20}}
> Response:
> {
>   "responseHeader": {
> "status": 0,
> "QTime": 0,
> "params": {
>   "q": "*:*",
>   "json.facet": "{trendFieldFacet:{type:terms, field:topics_f,  
> prefix:\"2\" }}",
>   "facet.field": "topics_f",
>   "indent": "true",
>   "facet.prefix": "2",
>   "rows": "0",
>   "wt": "json",
>   "facet": "true",
>   "_": "1444566142012"
> }
>   },
>   "response": {
> "numFound": 17,
> "start": 0,
> "docs": []
>   },
>   "facet_counts": {
> "facet_queries": {},
> "facet_fields": {
>   "topics_f": [
> "2/device/iphone",
> 4,
> "2/device/samsung",
> 4,
> "2/city/london",
> 1,
> "2/city/rome",
> 1,
> "2/device/other",
> 1
>   ]
> },
> "facet_dates": {},
> "facet_ranges": {},
> "facet_intervals": {},
> "facet_heatmaps": {}
>   },
>   "facets": {
> "count": 17,
> "trendFieldFacet": {
>   "buckets": [
> {
>   "val": "2/device/iphone",
>   "count": 4
> },
> {
>   "val": "2/device/samsung",
>   "count": 4
> },
> {
>   "val": "2/device/other",
>   "count": 1
> }
>   ]
> }
>   }
> }



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

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

[jira] [Commented] (SOLR-3191) field exclusion from fl

[Scott Stults (JIRA)]

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

Scott Stults commented on SOLR-3191:


Since this is essentially a wholesale rewrite of SolrReturnFields, would it be 
easier to manage if it was a separate extension of ReturnFields? That brings up 
another problem, namely, where we would configure that. We'd gain some 
flexibility in how the ResponseWriters treat return fields, so maybe that's a 
good place to select the particular ReturnFields implementation.

Kinda spitballing here because I know there is at least one ResponseWriter that 
requires special handling (CSV) and I suspect GeoJSONResponseWriter might need 
more (haven't looked yet).

> field exclusion from fl
> ---
>
> Key: SOLR-3191
> URL: https://issues.apache.org/jira/browse/SOLR-3191
> Project: Solr
>  Issue Type: Improvement
>Reporter: Luca Cavanna
>Priority: Minor
> Attachments: SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch, 
> SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch
>
>
> I think it would be useful to add a way to exclude field from the Solr 
> response. If I have for example 100 stored fields and I want to return all of 
> them but one, it would be handy to list just the field I want to exclude 
> instead of the 99 fields for inclusion through fl.



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

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

[jira] [Updated] (SOLR-7826) Permission issues when creating cores with bin/solr

[Binoy Dalal (JIRA)]

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

Binoy Dalal updated SOLR-7826:
--
Attachment: SOLR-7826.patch

> Permission issues when creating cores with bin/solr
> ---
>
> Key: SOLR-7826
> URL: https://issues.apache.org/jira/browse/SOLR-7826
> Project: Solr
>  Issue Type: Improvement
>Reporter: Shawn Heisey
>Priority: Minor
>  Labels: newdev
> Attachments: SOLR-7826.patch
>
>
> Ran into an interesting situation on IRC today.
> Solr has been installed as a service using the shell script 
> install_solr_service.sh ... so it is running as an unprivileged user.
> User is running "bin/solr create" as root.  This causes permission problems, 
> because the script creates the core's instanceDir with root ownership, then 
> when Solr is instructed to actually create the core, it cannot create the 
> dataDir.
> Enhancement idea:  When the install script is used, leave breadcrumbs 
> somewhere so that the "create core" section of the main script can find it 
> and su to the user specified during install.



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

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

[jira] [Assigned] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reassigned SOLR-8914:
---

Assignee: Shalin Shekhar Mangar

> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
> 
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-8914.patch, SOLR-8914.patch, SOLR-8914.patch, 
> SOLR-8914.patch, jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt, 
> live_node_mentions_port56361_with_threadIds.log.txt, 
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the 
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7 
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a 
> MiniSolrCloudCluster & several clients are initialized -- before any code 
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in 
> the logs, so i'm filing this jira with my analysis in the hopes that someone 
> else can help make sense of it.



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

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

[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8914:
--

FWIW these both passed for me.

> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
> 
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8914.patch, SOLR-8914.patch, SOLR-8914.patch, 
> SOLR-8914.patch, jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt, 
> live_node_mentions_port56361_with_threadIds.log.txt, 
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the 
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7 
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a 
> MiniSolrCloudCluster & several clients are initialized -- before any code 
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in 
> the logs, so i'm filing this jira with my analysis in the hopes that someone 
> else can help make sense of it.



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

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

[jira] [Comment Edited] (SOLR-7826) Permission issues when creating cores with bin/solr

[Binoy Dalal (JIRA)]

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

Binoy Dalal edited comment on SOLR-7826 at 4/11/16 5:49 PM:


I'm having a bit of an issue with the current implementation so I'll just 
outline my approach, and state the problem:
1) Detect the user while solr is first started.
2) Pass the user detected in (1) to SolrCLI and the option if any.
3) Perform the user and option check if user=root.
4) Return appropriate message.

I'm facing a problem in step 1 and 2. I am not sure of how to store the 
detected user so that the next time the script is run, it can find that user. 
I've tried exporting the variable but that doesn't seem to work without adding 
the variable to permanent list of environment variables, which I don't think is 
something that should be done.

Another option that I've thought of is to write the user id to a file like the 
solr port is written and use that in subsequent script calls for user checking, 
and delete it once solr is stopped. I think this would be a good approach.

Please advise.

-- EDIT --
I've tested out the file creation approach and it works fine.

To recap the requirements, to see if I missed something:
1) If solr is started as root, and user tries to create a core as root then 
display warning with the option to user.
2) If solr is started as root, and user tries to create a core as root with 
option, allow creation of core.
3) If solr is started as an unprivileged user and creation of a core is 
attempted with root, an exception is thrown with the default behaviour (no 
changes to be made here).

Let me know if I've missed something.

Thanks.


was (Author: binoydala...@gmail.com):
I'm having a bit of an issue with the current implementation so I'll just 
outline my approach, and state the problem:
1) Detect the user while solr is first started.
2) Pass the user detected in (1) to SolrCLI and the option if any.
3) Perform the user and option check if user=root.
4) Return appropriate message.

I'm facing a problem in step 1 and 2. I am not sure of how to store the 
detected user so that the next time the script is run, it can find that user. 
I've tried exporting the variable but that doesn't seem to work without adding 
the variable to permanent list of environment variables, which I don't think is 
something that should be done.

Another option that I've thought of is to write the user id to a file like the 
solr port is written and use that in subsequent script calls for user checking, 
and delete it once solr is stopped. I think this would be a good approach.

Please advise.

--EDIT--
I've tested out the file creation approach and it works fine.

To recap the requirements, to see if I missed something:
1) If solr is started as root, and user tries to create a core as root then 
display warning with the option to user.
2) If solr is started as root, and user tries to create a core as root with 
option, allow creation of core.
3) If solr is started as an unprivileged user and creation of a core is 
attempted with root, an exception is thrown with the default behaviour (no 
changes to be made here).

Let me know if I've missed something.

Thanks.

> Permission issues when creating cores with bin/solr
> ---
>
> Key: SOLR-7826
> URL: https://issues.apache.org/jira/browse/SOLR-7826
> Project: Solr
>  Issue Type: Improvement
>Reporter: Shawn Heisey
>Priority: Minor
>  Labels: newdev
>
> Ran into an interesting situation on IRC today.
> Solr has been installed as a service using the shell script 
> install_solr_service.sh ... so it is running as an unprivileged user.
> User is running "bin/solr create" as root.  This causes permission problems, 
> because the script creates the core's instanceDir with root ownership, then 
> when Solr is instructed to actually create the core, it cannot create the 
> dataDir.
> Enhancement idea:  When the install script is used, leave breadcrumbs 
> somewhere so that the "create core" section of the main script can find it 
> and su to the user specified during install.



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

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

[jira] [Comment Edited] (SOLR-7826) Permission issues when creating cores with bin/solr

[Binoy Dalal (JIRA)]

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

Binoy Dalal edited comment on SOLR-7826 at 4/11/16 5:45 PM:


I'm having a bit of an issue with the current implementation so I'll just 
outline my approach, and state the problem:
1) Detect the user while solr is first started.
2) Pass the user detected in (1) to SolrCLI and the option if any.
3) Perform the user and option check if user=root.
4) Return appropriate message.

I'm facing a problem in step 1 and 2. I am not sure of how to store the 
detected user so that the next time the script is run, it can find that user. 
I've tried exporting the variable but that doesn't seem to work without adding 
the variable to permanent list of environment variables, which I don't think is 
something that should be done.

Another option that I've thought of is to write the user id to a file like the 
solr port is written and use that in subsequent script calls for user checking, 
and delete it once solr is stopped. I think this would be a good approach.

Please advise.

--EDIT--
I've tested out the file creation approach and it works fine.

To recap the requirements, to see if I missed something:
1) If solr is started as root, and user tries to create a core as root then 
display warning with the option to user.
2) If solr is started as root, and user tries to create a core as root with 
option, allow creation of core.
3) If solr is started as an unprivileged user and creation of a core is 
attempted with root, an exception is thrown with the default behaviour (no 
changes to be made here).

Let me know if I've missed something.

Thanks.


was (Author: binoydala...@gmail.com):
I'm having a bit of an issue with the current implementation so I'll just 
outline my approach, and state the problem:
1) Detect the user while solr is first started.
2) Pass the user detected in (1) to SolrCLI and the option if any.
3) Perform the user and option check if user=root.
4) Return appropriate message.

I'm facing a problem in step 1 and 2. I am not sure of how to store the 
detected user so that the next time the script is run, it can find that user. 
I've tried exporting the variable but that doesn't seem to work without adding 
the variable to permanent list of environment variables, which I don't think is 
something that should be done.

Another option that I've thought of is to write the user id to a file like the 
solr port is written and use that in subsequent script calls for user checking, 
and delete it once solr is stopped. I think this would be a good approach.

Please advise.

> Permission issues when creating cores with bin/solr
> ---
>
> Key: SOLR-7826
> URL: https://issues.apache.org/jira/browse/SOLR-7826
> Project: Solr
>  Issue Type: Improvement
>Reporter: Shawn Heisey
>Priority: Minor
>  Labels: newdev
>
> Ran into an interesting situation on IRC today.
> Solr has been installed as a service using the shell script 
> install_solr_service.sh ... so it is running as an unprivileged user.
> User is running "bin/solr create" as root.  This causes permission problems, 
> because the script creates the core's instanceDir with root ownership, then 
> when Solr is instructed to actually create the core, it cannot create the 
> dataDir.
> Enhancement idea:  When the install script is used, leave breadcrumbs 
> somewhere so that the "create core" section of the main script can find it 
> and su to the user specified during install.



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

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

[jira] [Commented] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8914:
--

Thanks Erick!  I'll give this a shot myself.

I'm going to venture to say, however, that we should move forward on committing 
this patch.  Whether or not there are any lingering race conditions that could 
manifest in rare cases, the patch for sure fixes some race conditions that we 
can both see from inspection and reproduce with a lot of reliability.  So I 
think this patch makes things much better regardless of whether we've ironed 
out every last race condition.

> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
> 
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8914.patch, SOLR-8914.patch, SOLR-8914.patch, 
> SOLR-8914.patch, jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt, 
> live_node_mentions_port56361_with_threadIds.log.txt, 
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the 
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7 
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a 
> MiniSolrCloudCluster & several clients are initialized -- before any code 
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in 
> the logs, so i'm filing this jira with my analysis in the hopes that someone 
> else can help make sense of it.



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

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 514 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 53072 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.classification...
  [javadoc] Loading source files for package 
org.apache.lucene.classification.document...
  [javadoc] Loading source files for package 
org.apache.lucene.classification.utils...
  [javadoc] Constructing Javadoc information...
  [javadoc] javadoc: warning - Error reading file: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/docs/classification/../group/package-list
  [javadoc] Standard Doclet version 1.8.0_72
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/docs/classification/help-doc.html...
  [javadoc] Note: Custom tags that were not seen:  @lucene.internal
  [javadoc] 1 warning

BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:740: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/build.xml:101: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:138: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build.xml:246: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2187:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/classification/build.xml:46:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/module-build.xml:78:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/common-build.xml:2163:
 Javadocs warnings were found!

Total time: 88 minutes 41 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-7826) Permission issues when creating cores with bin/solr

[Binoy Dalal (JIRA)]

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

Binoy Dalal commented on SOLR-7826:
---

I'm having a bit of an issue with the current implementation so I'll just 
outline my approach, and state the problem:
1) Detect the user while solr is first started.
2) Pass the user detected in (1) to SolrCLI and the option if any.
3) Perform the user and option check if user=root.
4) Return appropriate message.

I'm facing a problem in step 1 and 2. I am not sure of how to store the 
detected user so that the next time the script is run, it can find that user. 
I've tried exporting the variable but that doesn't seem to work without adding 
the variable to permanent list of environment variables, which I don't think is 
something that should be done.

Another option that I've thought of is to write the user id to a file like the 
solr port is written and use that in subsequent script calls for user checking, 
and delete it once solr is stopped. I think this would be a good approach.

Please advise.

> Permission issues when creating cores with bin/solr
> ---
>
> Key: SOLR-7826
> URL: https://issues.apache.org/jira/browse/SOLR-7826
> Project: Solr
>  Issue Type: Improvement
>Reporter: Shawn Heisey
>Priority: Minor
>  Labels: newdev
>
> Ran into an interesting situation on IRC today.
> Solr has been installed as a service using the shell script 
> install_solr_service.sh ... so it is running as an unprivileged user.
> User is running "bin/solr create" as root.  This causes permission problems, 
> because the script creates the core's instanceDir with root ownership, then 
> when Solr is instructed to actually create the core, it cannot create the 
> dataDir.
> Enhancement idea:  When the install script is used, leave breadcrumbs 
> somewhere so that the "create core" section of the main script can find it 
> and su to the user specified during install.



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

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 133 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/133/

1 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomTiny

Error Message:
Cannot determine sidedness because check point is on plane.

Stack Trace:
java.lang.IllegalArgumentException: Cannot determine sidedness because check 
point is on plane.
at 
__randomizedtesting.SeedInfo.seed([64DEF3304EDDBC9:4F0A31755ACCE365]:0)
at 
org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:95)
at 
org.apache.lucene.spatial3d.geom.GeoRectangle.(GeoRectangle.java:134)
at 
org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:108)
at 
org.apache.lucene.spatial3d.Geo3DPoint.newBoxQuery(Geo3DPoint.java:125)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.random3DQuery(TestGeo3DPoint.java:563)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.verify(TestGeo3DPoint.java:747)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.doTestRandom(TestGeo3DPoint.java:518)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomTiny(TestGeo3DPoint.java:441)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 9011 lines...]
   [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
   [junit4]   2> NOTE: reproduce with: ant test  

Re: [CONF] Apache Solr Reference Guide > Upgrading a Solr Cluster

[Chris Hostetter]

: > ...but maybe we should move it up into the "Run the Solr Installation 
: > Script" subsection and generalize it?
: >
: > "NOTE: the remainder of this doc assumes you use the install script 
: > defaults, some directories and filenames may change if you override 
: > options, such as the "-s service_name" option" 

: I do think the doc should spell out the path changes introduced by a
: different service name, in one place, probably at the beginning of the
: "installation script" section -- but this is not *necessary*, and I can
: accept that the doc will be easier to maintain if it's not there.

Having reviewd both docs a bit more, i think they are bettter treated 
differently...

---

1) As a brand new user learning how to install...

https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production#TakingSolrtoProduction-RuntheSolrInstallationScript

after introducing the basic command to run the installer, and then showing 
the equivilent command with every option spelled out...

sudo bash ./install_solr_service.sh solr-X.Y.Z.tgz
sudo bash ./install_solr_service.sh solr-X.Y.Z.tgz -i /opt -d /var/solr -u solr 
-s solr -p 8983

...there are 4 subsections - 2 of which have notes like this...

"By default, the installation script uses /var/solr/data. If the -d option 
is used on the install script, then this will change to the data 
subdirectory in the location given to the -d option."

and

"Take a moment to inspect the contents of the /etc/default/solr.in.sh 
file, which is the default path setup by the installation script. If you 
used the -s option on the install script to change the name of the 
service, then the first part of the filename will be different.  For a 
service named solr-demo, the file will be named 
/etc/default/solr-demo.in.sh."

...I think those absolutely make sense in that "new user" context, to help 
you get an idea how changingthe install options affects the subsequent 
commants -- i actaully think we should probably add a similar note to the 
"init.d script" subsection...

"If you used the -s option on the install script to change the name of the 
service, then the filename used in the /etc/init.d/ directory will be 
different." 

---

2) The ugprading page has a diff target user...

https://cwiki.apache.org/confluence/display/solr/Upgrading+a+Solr+Cluster

If you are upgrading you are already an existing solr users, and you 
should already be familiar with the basic concepts of the solr service 
scripts -- the very first thing thta page does is give you a link to
the "Taking Solr to Production" to say you must have installed Solr that 
way to use those steps -- we cn assume you are familiar with those 
concepts and have read that info.

On this Upgrading page -- i think it's fine that we have a single warning 
callout box that says: "The steps outlined on this page assume you use the 
default service name of "solr". If you use an alternate service name, some 
paths and commands will have to be modified accordingly."

...the one thing i think we should add to that though is "...alternate 
service name or installation directory, some of the paths and commands..." 
... since even if you didn't override "-s solr" when you installed, if you 
overrode "-d /var/solr" or "-i /opt" then you'll have to tweak things as 
well.

---

Sound good?



-Hoss
http://www.lucidworks.com/

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

Re: [1/2] lucene-solr:master: LUCENE-7196 - guaranteed class coverage in split indexes through grouping by class

[Adrien Grand]

Hi Tommaso,

Le lun. 11 avr. 2016 à 10:12,  a écrit :

> +
>
> +
> +HashMap mapping = new HashMap<>();
> +mapping.put(classFieldName, UninvertingReader.Type.SORTED);
> +UninvertingReader uninvertingReader = new
> UninvertingReader(originalIndex, mapping);
> +  IndexSearcher indexSearcher = new IndexSearcher(uninvertingReader);
> +  GroupingSearch gs = new GroupingSearch(classFieldName);
> +  gs.setGroupSort(Sort.INDEXORDER);
> +  gs.setSortWithinGroup(Sort.INDEXORDER);
> +  gs.setAllGroups(true);
> +  gs.setGroupDocsLimit(originalIndex.maxDoc());
> +  TopGroups topGroups = gs.search(indexSearcher, new
> MatchAllDocsQuery(), 0, (int) noOfClasses);
>

I have been looking at this commit because of the javadocs failures and it
feels wrong to me that we are adding dependencies to the misc and grouping
modules just for this utility class that splits indices? I think we could
make it work in a similar way to PKIndexSplitter which would not require
grouping or UninvertingReader.

Re: Lucene/Solr 5.5.1

[Ishan Chattopadhyaya]

Hi Anshum,

I'd like someone to backport the following:
SOLR-8838
SOLR-8082
SOLR-8865

These are mentioned in the bug-fix section of 6.0, so I agree with Yonik
that we should perhaps look at all of those changes.
Thanks and regards,
Ishan


On Mon, Apr 11, 2016 at 9:55 PM, Yonik Seeley  wrote:

> On Sun, Apr 10, 2016 at 12:59 PM, Anshum Gupta 
> wrote:
> > Hi,
> >
> > I would like to release 5.5.1, specially for to SOLR-8725.
> >
> > SOLR-8642 in 5.5 stops people from upgrading to 5.5 and a lot of users
> have
> > spoken about it on the mailing list and the JIRA.
> >
> > I would like to start the process towards the end of the coming week.
>
> At a minimum, we should prob look at the whole bug-fix section of 6.0
>
> -Yonik
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Resolved] (LUCENE-7201) Test failure for geo3d bbox queries in TestGeo3DPoint

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-7201.
-
   Resolution: Fixed
Fix Version/s: 6.x
   master

> Test failure for geo3d bbox queries in TestGeo3DPoint
> -
>
> Key: LUCENE-7201
> URL: https://issues.apache.org/jira/browse/LUCENE-7201
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
>
> Here's the test failure, which looks like a garden-variety attempt to create 
> an illegal shape:
> {code}
>[junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
>[junit4] IGNOR/A 0.02s J0 | TestGeo3DPoint.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
> -Dtests.method=testRandomTiny -Dtests.seed=92AFBC246156F30B -Dtests.slow=true 
> -Dtests.locale=it-CH -Dtests.timezone=PRC -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.05s J0 | TestGeo3DPoint.testRandomTiny <<<
>[junit4]> Throwable #1: java.lang.IllegalArgumentException: Cannot 
> determine sidedness because check point is on plane.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([92AFBC246156F30B:DBE862623F77CBA7]:0)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:95)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoNorthRectangle.(GeoNorthRectangle.java:109)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:103)
>[junit4]>at 
> org.apache.lucene.spatial3d.Geo3DPoint.newBoxQuery(Geo3DPoint.java:125)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.random3DQuery(TestGeo3DPoint.java:563)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.verify(TestGeo3DPoint.java:747)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.doTestRandom(TestGeo3DPoint.java:518)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomTiny(TestGeo3DPoint.java:441)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: 
> codec=FastCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST,
>  chunkSize=9, maxDocsPerChunk=9, blockSize=931), 
> termVectorsFormat=CompressingTermVectorsFormat(compressionMode=FAST, 
> chunkSize=9, blockSize=931)), sim=RandomSimilarity(queryNorm=true,coord=no): 
> {}, locale=it-CH, timezone=PRC
>[junit4]   2> NOTE: Windows 7 6.1 amd64/Oracle Corporation 1.8.0_45 
> (64-bit)/cpus=4,threads=1,free=219878656,total=262668288
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DPoint]
>[junit4] Completed [10/10 (1!)] on J0 in 11.15s, 13 tests, 1 error, 1 
> skipped
>  <<< FAILURES!
> {code}



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

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

[jira] [Commented] (LUCENE-7201) Test failure for geo3d bbox queries in TestGeo3DPoint

[ASF subversion and git services (JIRA)]

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

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

Commit 5f4af54f9900f3c05a18fe16584e72976ca1bd3b in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5f4af54 ]

LUCENE-7201: Handle backside whole-world case for bbox generation.


> Test failure for geo3d bbox queries in TestGeo3DPoint
> -
>
> Key: LUCENE-7201
> URL: https://issues.apache.org/jira/browse/LUCENE-7201
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> Here's the test failure, which looks like a garden-variety attempt to create 
> an illegal shape:
> {code}
>[junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
>[junit4] IGNOR/A 0.02s J0 | TestGeo3DPoint.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
> -Dtests.method=testRandomTiny -Dtests.seed=92AFBC246156F30B -Dtests.slow=true 
> -Dtests.locale=it-CH -Dtests.timezone=PRC -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.05s J0 | TestGeo3DPoint.testRandomTiny <<<
>[junit4]> Throwable #1: java.lang.IllegalArgumentException: Cannot 
> determine sidedness because check point is on plane.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([92AFBC246156F30B:DBE862623F77CBA7]:0)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:95)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoNorthRectangle.(GeoNorthRectangle.java:109)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:103)
>[junit4]>at 
> org.apache.lucene.spatial3d.Geo3DPoint.newBoxQuery(Geo3DPoint.java:125)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.random3DQuery(TestGeo3DPoint.java:563)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.verify(TestGeo3DPoint.java:747)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.doTestRandom(TestGeo3DPoint.java:518)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomTiny(TestGeo3DPoint.java:441)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: 
> codec=FastCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST,
>  chunkSize=9, maxDocsPerChunk=9, blockSize=931), 
> termVectorsFormat=CompressingTermVectorsFormat(compressionMode=FAST, 
> chunkSize=9, blockSize=931)), sim=RandomSimilarity(queryNorm=true,coord=no): 
> {}, locale=it-CH, timezone=PRC
>[junit4]   2> NOTE: Windows 7 6.1 amd64/Oracle Corporation 1.8.0_45 
> (64-bit)/cpus=4,threads=1,free=219878656,total=262668288
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DPoint]
>[junit4] Completed [10/10 (1!)] on J0 in 11.15s, 13 tests, 1 error, 1 
> skipped
>  <<< FAILURES!
> {code}



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

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

[jira] [Commented] (LUCENE-7201) Test failure for geo3d bbox queries in TestGeo3DPoint

[ASF subversion and git services (JIRA)]

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

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

Commit a03c0b806db0c6cd54fcf03abfc0ff86ffb944f1 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a03c0b8 ]

LUCENE-7201: Handle illegal rectangles during testing.


> Test failure for geo3d bbox queries in TestGeo3DPoint
> -
>
> Key: LUCENE-7201
> URL: https://issues.apache.org/jira/browse/LUCENE-7201
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> Here's the test failure, which looks like a garden-variety attempt to create 
> an illegal shape:
> {code}
>[junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
>[junit4] IGNOR/A 0.02s J0 | TestGeo3DPoint.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
> -Dtests.method=testRandomTiny -Dtests.seed=92AFBC246156F30B -Dtests.slow=true 
> -Dtests.locale=it-CH -Dtests.timezone=PRC -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.05s J0 | TestGeo3DPoint.testRandomTiny <<<
>[junit4]> Throwable #1: java.lang.IllegalArgumentException: Cannot 
> determine sidedness because check point is on plane.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([92AFBC246156F30B:DBE862623F77CBA7]:0)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:95)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoNorthRectangle.(GeoNorthRectangle.java:109)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:103)
>[junit4]>at 
> org.apache.lucene.spatial3d.Geo3DPoint.newBoxQuery(Geo3DPoint.java:125)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.random3DQuery(TestGeo3DPoint.java:563)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.verify(TestGeo3DPoint.java:747)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.doTestRandom(TestGeo3DPoint.java:518)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomTiny(TestGeo3DPoint.java:441)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: 
> codec=FastCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST,
>  chunkSize=9, maxDocsPerChunk=9, blockSize=931), 
> termVectorsFormat=CompressingTermVectorsFormat(compressionMode=FAST, 
> chunkSize=9, blockSize=931)), sim=RandomSimilarity(queryNorm=true,coord=no): 
> {}, locale=it-CH, timezone=PRC
>[junit4]   2> NOTE: Windows 7 6.1 amd64/Oracle Corporation 1.8.0_45 
> (64-bit)/cpus=4,threads=1,free=219878656,total=262668288
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DPoint]
>[junit4] Completed [10/10 (1!)] on J0 in 11.15s, 13 tests, 1 error, 1 
> skipped
>  <<< FAILURES!
> {code}



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

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

[jira] [Commented] (LUCENE-7201) Test failure for geo3d bbox queries in TestGeo3DPoint

[ASF subversion and git services (JIRA)]

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

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

Commit 83bde55865f56a5ffe660e0bde780b49b6adc4f8 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=83bde55 ]

LUCENE-7201: Handle illegal rectangles during testing.


> Test failure for geo3d bbox queries in TestGeo3DPoint
> -
>
> Key: LUCENE-7201
> URL: https://issues.apache.org/jira/browse/LUCENE-7201
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> Here's the test failure, which looks like a garden-variety attempt to create 
> an illegal shape:
> {code}
>[junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
>[junit4] IGNOR/A 0.02s J0 | TestGeo3DPoint.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
> -Dtests.method=testRandomTiny -Dtests.seed=92AFBC246156F30B -Dtests.slow=true 
> -Dtests.locale=it-CH -Dtests.timezone=PRC -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.05s J0 | TestGeo3DPoint.testRandomTiny <<<
>[junit4]> Throwable #1: java.lang.IllegalArgumentException: Cannot 
> determine sidedness because check point is on plane.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([92AFBC246156F30B:DBE862623F77CBA7]:0)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:95)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoNorthRectangle.(GeoNorthRectangle.java:109)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:103)
>[junit4]>at 
> org.apache.lucene.spatial3d.Geo3DPoint.newBoxQuery(Geo3DPoint.java:125)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.random3DQuery(TestGeo3DPoint.java:563)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.verify(TestGeo3DPoint.java:747)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.doTestRandom(TestGeo3DPoint.java:518)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomTiny(TestGeo3DPoint.java:441)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: 
> codec=FastCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST,
>  chunkSize=9, maxDocsPerChunk=9, blockSize=931), 
> termVectorsFormat=CompressingTermVectorsFormat(compressionMode=FAST, 
> chunkSize=9, blockSize=931)), sim=RandomSimilarity(queryNorm=true,coord=no): 
> {}, locale=it-CH, timezone=PRC
>[junit4]   2> NOTE: Windows 7 6.1 amd64/Oracle Corporation 1.8.0_45 
> (64-bit)/cpus=4,threads=1,free=219878656,total=262668288
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DPoint]
>[junit4] Completed [10/10 (1!)] on J0 in 11.15s, 13 tests, 1 error, 1 
> skipped
>  <<< FAILURES!
> {code}



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

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

[jira] [Commented] (LUCENE-7201) Test failure for geo3d bbox queries in TestGeo3DPoint

[ASF subversion and git services (JIRA)]

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

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

Commit 05dc90215ad69c16c0284fdbe9e5df2cf4bf5f8e in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=05dc902 ]

LUCENE-7201: Handle backside whole-world case for bbox generation.


> Test failure for geo3d bbox queries in TestGeo3DPoint
> -
>
> Key: LUCENE-7201
> URL: https://issues.apache.org/jira/browse/LUCENE-7201
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> Here's the test failure, which looks like a garden-variety attempt to create 
> an illegal shape:
> {code}
>[junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
>[junit4] IGNOR/A 0.02s J0 | TestGeo3DPoint.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
> -Dtests.method=testRandomTiny -Dtests.seed=92AFBC246156F30B -Dtests.slow=true 
> -Dtests.locale=it-CH -Dtests.timezone=PRC -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.05s J0 | TestGeo3DPoint.testRandomTiny <<<
>[junit4]> Throwable #1: java.lang.IllegalArgumentException: Cannot 
> determine sidedness because check point is on plane.
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([92AFBC246156F30B:DBE862623F77CBA7]:0)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.SidedPlane.(SidedPlane.java:95)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoNorthRectangle.(GeoNorthRectangle.java:109)
>[junit4]>at 
> org.apache.lucene.spatial3d.geom.GeoBBoxFactory.makeGeoBBox(GeoBBoxFactory.java:103)
>[junit4]>at 
> org.apache.lucene.spatial3d.Geo3DPoint.newBoxQuery(Geo3DPoint.java:125)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.random3DQuery(TestGeo3DPoint.java:563)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.verify(TestGeo3DPoint.java:747)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.doTestRandom(TestGeo3DPoint.java:518)
>[junit4]>at 
> org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomTiny(TestGeo3DPoint.java:441)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: 
> codec=FastCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST,
>  chunkSize=9, maxDocsPerChunk=9, blockSize=931), 
> termVectorsFormat=CompressingTermVectorsFormat(compressionMode=FAST, 
> chunkSize=9, blockSize=931)), sim=RandomSimilarity(queryNorm=true,coord=no): 
> {}, locale=it-CH, timezone=PRC
>[junit4]   2> NOTE: Windows 7 6.1 amd64/Oracle Corporation 1.8.0_45 
> (64-bit)/cpus=4,threads=1,free=219878656,total=262668288
>[junit4]   2> NOTE: All tests run in this JVM: [TestGeo3DPoint]
>[junit4] Completed [10/10 (1!)] on J0 in 11.15s, 13 tests, 1 error, 1 
> skipped
>  <<< FAILURES!
> {code}



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

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

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 32 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/32/

No tests ran.

Build Log:
[...truncated 7637 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.classification...
  [javadoc] Loading source files for package 
org.apache.lucene.classification.document...
  [javadoc] Loading source files for package 
org.apache.lucene.classification.utils...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.8.0_74
  [javadoc] javadoc: warning - Error reading file: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/docs/classification/../group/package-list
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/docs/classification/help-doc.html...
  [javadoc] Note: Custom tags that were not seen:  @lucene.internal
  [javadoc] 1 warning

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/build.xml:520: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build.xml:246:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/common-build.xml:2187:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/classification/build.xml:46:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/module-build.xml:78:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/common-build.xml:2163:
 Javadocs warnings were found!

Total time: 4 minutes 11 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any




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

Re: [CONF] Apache Solr Reference Guide > Upgrading a Solr Cluster

[Shawn Heisey]

On 4/11/2016 10:34 AM, Chris Hostetter wrote:
> ...but maybe we should move it up into the "Run the Solr Installation 
> Script" subsection and generalize it?
>
> "NOTE: the remainder of this doc assumes you use the install script 
> defaults, some directories and filenames may change if you override 
> options, such as the "-s service_name" option" 
>
> WDYT?

I do think the doc should spell out the path changes introduced by a
different service name, in one place, probably at the beginning of the
"installation script" section -- but this is not *necessary*, and I can
accept that the doc will be easier to maintain if it's not there.

Thanks,
Shawn


-
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 # 1071 - Still Failing

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.cloud.BasicDistributedZkTest.test

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([9AB9608D86A8F172]:0)


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

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

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


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud

Error Message:
ObjectTracker found 3 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, SolrCore]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 3 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, SolrCore]
at __randomizedtesting.SeedInfo.seed([9AB9608D86A8F172]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([9AB9608D86A8F172:4D1D6F18326D4E]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:780)
at 
org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 

Re: [CONF] Apache Solr Reference Guide > Upgrading a Solr Cluster

[Chris Hostetter]

: > The goal here should be to keep the upgrade steps simple, focus on the 
: > common case, and have minimal distractions for the uncommon cases.
: 
: I moved it, then took it out after thinking about it a little more.  I
: see that the "taking solr to production" page already has this specific

Hmm -- but the same working on those 2 diff pages doesn't really seem like 
an apples to apples comparison though ... on the Taking Solr to Production 
page we *just* introduced for thefirst time the install script and the 
options ot change the service name, so it makes a bit more sense to 
explicitly call out (in an inline context) how it will affect the file 
names...


...but maybe we should move it up into the "Run the Solr Installation 
Script" subsection and generalize it?

"NOTE: the remainder of this doc assumes you use the install script 
defaults, some directories and filenames may change if you override 
options, such as the "-s service_name" option" 

WDYT?

: note, although that page mentions solr5 and has a bunch of examples
: containing "5.0.0".

yeah ... kind of a seperate issue: i'm going to audit all mentions of 
"Solr 5" or "5.0" in the ref guide ASAP.




-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (SOLR-3191) field exclusion from fl

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-3191:
--

Ryan responded for <1>, so that's apparently not a problem.

> field exclusion from fl
> ---
>
> Key: SOLR-3191
> URL: https://issues.apache.org/jira/browse/SOLR-3191
> Project: Solr
>  Issue Type: Improvement
>Reporter: Luca Cavanna
>Priority: Minor
> Attachments: SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch, 
> SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch
>
>
> I think it would be useful to add a way to exclude field from the Solr 
> response. If I have for example 100 stored fields and I want to return all of 
> them but one, it would be handy to list just the field I want to exclude 
> instead of the 99 fields for inclusion through fl.



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

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

RE: [jira] [Commented] (SOLR-8010) Allow WordBreakSolrSpellChecker to break when one word matches

[Edwards, Joshua]

Hey, guys -

I re-based this pull request and integrated the changes that I saw since last 
time I submitted it.  It should be a pretty straight-forward piece of 
functionality to add, so if a committer could check it out and add it (or give 
me feedback on why it can't be added), I'd greatly appreciate it, so that I 
don't have to support the functionality locally.

Thanks,
Josh

-Original Message-
From: ASF GitHub Bot (JIRA) [mailto:j...@apache.org] 
Sent: Monday, April 11, 2016 12:24 PM
To: dev@lucene.apache.org
Subject: [jira] [Commented] (SOLR-8010) Allow WordBreakSolrSpellChecker to 
break when one word matches


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

ASF GitHub Bot commented on SOLR-8010:
--

GitHub user Admje14 opened a pull request:

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

SOLR-8010 Adding the ability to optionally enable breaking words wher…

…e one side is a word but the other is not.  Integrated with re-based trunk 
to re-submit the pull request.

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

$ git pull https://github.com/Admje14/lucene-solr-1 master

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

https://github.com/apache/lucene-solr/pull/28.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 #28


commit 292a1ba07a4c42893acedc85c0755fe0e3167a76
Author: Josh Edwards 
Date:   2016-04-11T16:19:28Z

SOLR-8010 Adding the ability to optionally enable breaking words where one 
side is a word but the other is not.  Integrated with re-based trunk to 
re-submit the pull request.




> Allow WordBreakSolrSpellChecker to break when one word matches
> --
>
> Key: SOLR-8010
> URL: https://issues.apache.org/jira/browse/SOLR-8010
> Project: Solr
>  Issue Type: Improvement
>  Components: spellchecker
>Affects Versions: 4.10.4, 5.3
>Reporter: Joshua Edwards
> Attachments: WordBreakDontRequireWordOnBothSides-trunk.patch, 
> WordBreakDontRequireWordOnBothSides.patch
>
>
> The WordBreakSolrSpellChecker only works if both words that are being broken 
> are in the dictionary.  This prevents the spell checker from breaking in 
> other valid use cases - such as when one of the words has a synonym that is 
> in the dictionary, or when one of the words is misspelled.  I would like to 
> enable (via configuration) the option to break when one of the two words is 
> in the dictionary, but the other is not.  



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

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




The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.

Re: Lucene/Solr 5.5.1

[Yonik Seeley]

On Sun, Apr 10, 2016 at 12:59 PM, Anshum Gupta  wrote:
> Hi,
>
> I would like to release 5.5.1, specially for to SOLR-8725.
>
> SOLR-8642 in 5.5 stops people from upgrading to 5.5 and a lot of users have
> spoken about it on the mailing list and the JIRA.
>
> I would like to start the process towards the end of the coming week.

At a minimum, we should prob look at the whole bug-fix section of 6.0

-Yonik

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

[jira] [Commented] (SOLR-8010) Allow WordBreakSolrSpellChecker to break when one word matches

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8010:
--

GitHub user Admje14 opened a pull request:

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

SOLR-8010 Adding the ability to optionally enable breaking words wher…

…e one side is a word but the other is not.  Integrated with re-based trunk 
to re-submit the pull request.

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

$ git pull https://github.com/Admje14/lucene-solr-1 master

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

https://github.com/apache/lucene-solr/pull/28.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 #28


commit 292a1ba07a4c42893acedc85c0755fe0e3167a76
Author: Josh Edwards 
Date:   2016-04-11T16:19:28Z

SOLR-8010 Adding the ability to optionally enable breaking words where one 
side is a word but the other is not.  Integrated with re-based trunk to 
re-submit the pull request.




> Allow WordBreakSolrSpellChecker to break when one word matches
> --
>
> Key: SOLR-8010
> URL: https://issues.apache.org/jira/browse/SOLR-8010
> Project: Solr
>  Issue Type: Improvement
>  Components: spellchecker
>Affects Versions: 4.10.4, 5.3
>Reporter: Joshua Edwards
> Attachments: WordBreakDontRequireWordOnBothSides-trunk.patch, 
> WordBreakDontRequireWordOnBothSides.patch
>
>
> The WordBreakSolrSpellChecker only works if both words that are being broken 
> are in the dictionary.  This prevents the spell checker from breaking in 
> other valid use cases - such as when one of the words has a synonym that is 
> in the dictionary, or when one of the words is misspelled.  I would like to 
> enable (via configuration) the option to break when one of the two words is 
> in the dictionary, but the other is not.  



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

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

[GitHub] lucene-solr pull request: SOLR-8010 Adding the ability to optional...

[Admje14]

GitHub user Admje14 opened a pull request:

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

SOLR-8010 Adding the ability to optionally enable breaking words wher…

…e one side is a word but the other is not.  Integrated with re-based 
trunk to re-submit the pull request.

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

$ git pull https://github.com/Admje14/lucene-solr-1 master

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

https://github.com/apache/lucene-solr/pull/28.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 #28


commit 292a1ba07a4c42893acedc85c0755fe0e3167a76
Author: Josh Edwards 
Date:   2016-04-11T16:19:28Z

SOLR-8010 Adding the ability to optionally enable breaking words where one 
side is a word but the other is not.  Integrated with re-based trunk to 
re-submit the pull request.




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

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

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[ASF subversion and git services (JIRA)]

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

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

Commit 7c8d3e054ece4c046e350226a3d22ebe214dd0d1 in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c8d3e0 ]

SOLR-8029: Added tests for add, delete replica props


> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: master
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



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

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

[jira] [Commented] (SOLR-8902) ReturnFields can return fields that were not requested

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8902:
--

Thanks Ryan!

> ReturnFields can return fields that were not requested
> --
>
> Key: SOLR-8902
> URL: https://issues.apache.org/jira/browse/SOLR-8902
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 6.1, trunk
>
> Attachments: SOLR-8902.diff
>
>
> It looks like something changed that now returns all fields requested from 
> lucene, not just the ones request from solr.
> This is the difference between 'fields' and 'okFieldNames' in 
> SolrReturnFields.
> The logic here:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/SolrReturnFields.java#L141
> adds all the 'fields' to 'okFieldName'
> I think that should be removed



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

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