[jira] [Commented] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[
https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895885#comment-13895885
]
Michael McCandless commented on LUCENE-5440:
+1, it's nice to see how many OBS's you were able to cut over.
I especially loved seeing this pre-existing comment (again):
{noformat}
super(in, false); // -- not passing false here wasted about 3 hours of
my time!
{noformat}
Maybe if we added a FixedBitSet.ensureCapacity then we could use FBS
in Numeric/BinaryDocValuesWriter? Seems like we should decouple elasticity
and long vs int index?
I find it crazy that SloppyPhraseScorer seems to allocate a new bitset
for every .advance call?
Maybe we should rename FBS - IntFBS?
Add LongFixedBitSet and replace usage of OpenBitSet
---
Key: LUCENE-5440
URL: https://issues.apache.org/jira/browse/LUCENE-5440
Project: Lucene - Core
Issue Type: Improvement
Components: core/search
Reporter: Shai Erera
Assignee: Shai Erera
Attachments: LUCENE-5440.patch
Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I
wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing
more than 2.1B bits. It overcome some issues I've encountered with
OpenBitSet, such as the use of set/fastSet as well the implementation of
DocIdSet. I'll post a patch shortly and describe it in more detail.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5190) SolrEntityProcessor substitutes variables only once in child entities
[ https://issues.apache.org/jira/browse/SOLR-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895890#comment-13895890 ] Dominik Siebel commented on SOLR-5190: -- [~shalinmangar], [~jpountz] Is there any chance, this will be merged to branch lucene_solr_4_3 / lucene_solr_4_4 ? SolrEntityProcessor substitutes variables only once in child entities - Key: SOLR-5190 URL: https://issues.apache.org/jira/browse/SOLR-5190 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.4 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 4.5, 5.0 Attachments: SOLR-5190.patch As noted by users on the mailing list and elsewhere, SolrEntityProcessor cannot be used in a child entity because it substitutes variables only once. http://www.mail-archive.com/solr-user@lucene.apache.org/msg88002.html http://stackoverflow.com/questions/15734308/solrentityprocessor-is-called-only-once-for-sub-entities?lq=1 SOLR-3336 attempted to fix the problem by moving variable substitution to the doQuery method but that fix is not complete because the doQuery method is called only once. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[
https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-5440:
---
Attachment: LUCENE-5440.patch
bq. Maybe if we added a FixedBitSet.ensureCapacity
You're right. Added FixedBitSet.ensureCapacity.
bq. I find it crazy that SloppyPhraseScorer seems to allocate a new bitset
for every .advance call?
Me too, therefore I only added a TODO. I guess a quick fix would be to try and
share a single FixedBitSet and clear() it in each advance. Also I'd optimize
the scary {{while (bits.cardinality() 0)}}. Maybe in a separate issue?
bq. Maybe we should rename FBS - IntFBS?
We could, though it will generate a huge amount of changes, so if we want to do
it, I'll do it after we're done reviewing the patch (just rote rename). But
since it's public and useful API (i.e. even though it's marked internal, I
believe it's used wider than just Lucene), maybe we shouldn't? It's just a
rename...
BTW, I reviewed more Solr code and could use some guidance from someone who's
more familiar with it. Looks like a core class of Solr that uses OBS is
BitDocSet, but from what I can tell, it doesn't rely much on elasticity (e.g.
it documents that the given bitset should be at least of size maxDoc()). Also,
it (and other classes) sometimes use set/get and sometimes fast. So if someone
can confirm it's safe to change this class to use FixedBitSet (seems like we
don't even need Long here), I'll do it.
Add LongFixedBitSet and replace usage of OpenBitSet
---
Key: LUCENE-5440
URL: https://issues.apache.org/jira/browse/LUCENE-5440
Project: Lucene - Core
Issue Type: Improvement
Components: core/search
Reporter: Shai Erera
Assignee: Shai Erera
Attachments: LUCENE-5440.patch, LUCENE-5440.patch
Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I
wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing
more than 2.1B bits. It overcome some issues I've encountered with
OpenBitSet, such as the use of set/fastSet as well the implementation of
DocIdSet. I'll post a patch shortly and describe it in more detail.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5441) Decouple DocIdSet from OpenBitSet and FixedBitSet
Uwe Schindler created LUCENE-5441:
-
Summary: Decouple DocIdSet from OpenBitSet and FixedBitSet
Key: LUCENE-5441
URL: https://issues.apache.org/jira/browse/LUCENE-5441
Project: Lucene - Core
Issue Type: Task
Components: core/other
Affects Versions: 4.6.1
Reporter: Uwe Schindler
Fix For: 5.0
Back from the times of Lucene 2.4 when DocIdSet was introduced, we somehow kept
the stupid filters can return a BitSet directly in the code. So lots of
Filters return just FixedBitSet, because this is the superclass (ideally
interface) of FixedBitSet.
We should decouple that and *not* implement that abstract interface directly by
FixedBitSet. This leads to bugs e.g. in BlockJoin, because it used Filters in a
wrong way, just because it was always returning Bitsets. But some filters
actually don't do this.
I propose to let FixedBitSet (only in trunk, because that a major backwards
break) just have a method {{asDocIdSet()}}, that returns an anonymous instance
of DocIdSet: bits() returns the FixedBitSet itsself, iterator() returns a new
Iterator (like it always did) and the cost/cacheable methods return static
values.
Filters in trunk would need to be changed like that:
{code:java}
FixedBitSet bits =
...
return bits;
{code}
gets:
{code:java}
FixedBitSet bits =
...
return bits.asDocIdSet();
{code}
As this methods returns an anonymous DocIdSet, calling code can no longer rely
or check if the implementation behind is a FixedBitSet.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895917#comment-13895917 ] Mark Miller commented on SOLR-3854: --- Yeah, SOLR-5700 has been committed and is part of what I'm testing. Still seeing a lot of fails. Taking a look. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[
https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895920#comment-13895920
]
Steve Davids commented on SOLR-3854:
Oh, it could be because the extra call to {code}initSSLConfig(sslConfig,
keystorePath);{code} has been removed in SolrJettyTestBase.getSSLConfig() which
has now turned on SSL for tests that previously weren't configured to run SSL
since the initSSL method sets {code}
sslConfig.useSsl = false;
sslConfig.clientAuth = false;
{code}
SolrCloud does not work with https
--
Key: SOLR-3854
URL: https://issues.apache.org/jira/browse/SOLR-3854
Project: Solr
Issue Type: Bug
Reporter: Sami Siren
Assignee: Mark Miller
Fix For: 5.0, 4.7
Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch,
SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch,
SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch
There are a few places in current codebase that assume http is used. This
prevents using https when running solr in cloud mode.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5624) Enable QueryResultCache for CollapsingQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-5624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895921#comment-13895921 ] ASF subversion and git services commented on SOLR-5624: --- Commit 1566309 from [~joel.bernstein] in branch 'dev/trunk' [ https://svn.apache.org/r1566309 ] SOLR-5624: Guard against NPE during cache warming Enable QueryResultCache for CollapsingQParserPlugin --- Key: SOLR-5624 URL: https://issues.apache.org/jira/browse/SOLR-5624 Project: Solr Issue Type: Task Affects Versions: 4.6 Reporter: David Assignee: Joel Bernstein Fix For: 5.0, 4.7 Attachments: SOLR-5624.patch, SOLR-5624.patch, SOLR-5624.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5624) Enable QueryResultCache for CollapsingQParserPlugin
[ https://issues.apache.org/jira/browse/SOLR-5624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895924#comment-13895924 ] ASF subversion and git services commented on SOLR-5624: --- Commit 1566312 from [~joel.bernstein] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1566312 ] SOLR-5624: Guard against NPE during cache warming Enable QueryResultCache for CollapsingQParserPlugin --- Key: SOLR-5624 URL: https://issues.apache.org/jira/browse/SOLR-5624 Project: Solr Issue Type: Task Affects Versions: 4.6 Reporter: David Assignee: Joel Bernstein Fix For: 5.0, 4.7 Attachments: SOLR-5624.patch, SOLR-5624.patch, SOLR-5624.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895926#comment-13895926 ] Mark Miller commented on SOLR-3854: --- Yeah, I had pulled that out in the last patch I put up because it looked like a test bug, tossing out the randomized settings. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5709) Highlighting grouped duplicate docs from different shards with group.limit 1 throws ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/SOLR-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895928#comment-13895928
]
Steve Rowe commented on SOLR-5709:
--
I'll commit tomorrow if there are no objections.
Highlighting grouped duplicate docs from different shards with group.limit
1 throws ArrayIndexOutOfBoundsException
Key: SOLR-5709
URL: https://issues.apache.org/jira/browse/SOLR-5709
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 4.3, 4.4, 4.5, 4.6, 5.0
Reporter: Steve Rowe
Assignee: Steve Rowe
Attachments: SOLR-5709.patch
In a sharded (non-SolrCloud) deployment, if you index a document with the
same unique key value into more than one shard, and then try to highlight
grouped docs with more than one doc per group, where the grouped docs contain
at least one duplicate doc pair, you get an AIOOBE.
Here's the stack trace I got from such a situation, with 1 doc indexed into
each shard in a 2-shard index, with {{group.limit=2}}:
{noformat}
ERROR null:java.lang.ArrayIndexOutOfBoundsException: 1
at
org.apache.solr.handler.component.HighlightComponent.finishStage(HighlightComponent.java:185)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:328)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1916)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:758)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:412)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:136)
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.session.SessionHandler.doHandle(SessionHandler.java:229)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.server.handler.GzipHandler.handle(GzipHandler.java:301)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1077)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:724)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895929#comment-13895929
]
Mark Miller commented on SOLR-5476:
---
I just saw this fail again locally with the latest commit.
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895930#comment-13895930 ] Mark Miller commented on SOLR-3854: --- I'm working through each of them. I'll be done shortly I think. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895936#comment-13895936
]
Noble Paul commented on SOLR-5476:
--
I ran it around 20 times on my local box and could not get an error/failure .
I'll look at jenkins for failures
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5441) Decouple DocIdSet from OpenBitSet and FixedBitSet
[
https://issues.apache.org/jira/browse/LUCENE-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895937#comment-13895937
]
Shai Erera commented on LUCENE-5441:
+1 to make the separation, I was thinking exactly that while working on
LUCENE-5440. I wish also that DocIdSet (or some other interface) allowed you to
do set operations, e.g. like Solr's DocSet. This then makes
optimization-checking {{if (bits instanceof FixedBitSet)}} moot, you just call
docs.intersect(otherDocIdSet) and let the implementation decide if it can
optimize or not. It should then be pretty easy to implement a DocSet/DocIdSet
backed by a FixedBitSet?
Decouple DocIdSet from OpenBitSet and FixedBitSet
-
Key: LUCENE-5441
URL: https://issues.apache.org/jira/browse/LUCENE-5441
Project: Lucene - Core
Issue Type: Task
Components: core/other
Affects Versions: 4.6.1
Reporter: Uwe Schindler
Fix For: 5.0
Back from the times of Lucene 2.4 when DocIdSet was introduced, we somehow
kept the stupid filters can return a BitSet directly in the code. So lots
of Filters return just FixedBitSet, because this is the superclass (ideally
interface) of FixedBitSet.
We should decouple that and *not* implement that abstract interface directly
by FixedBitSet. This leads to bugs e.g. in BlockJoin, because it used Filters
in a wrong way, just because it was always returning Bitsets. But some
filters actually don't do this.
I propose to let FixedBitSet (only in trunk, because that a major backwards
break) just have a method {{asDocIdSet()}}, that returns an anonymous
instance of DocIdSet: bits() returns the FixedBitSet itsself, iterator()
returns a new Iterator (like it always did) and the cost/cacheable methods
return static values.
Filters in trunk would need to be changed like that:
{code:java}
FixedBitSet bits =
...
return bits;
{code}
gets:
{code:java}
FixedBitSet bits =
...
return bits.asDocIdSet();
{code}
As this methods returns an anonymous DocIdSet, calling code can no longer
rely or check if the implementation behind is a FixedBitSet.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895940#comment-13895940
]
Mark Miller commented on SOLR-5476:
---
I've seen it fail a couple times already - something about failing to reorder.
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5190) SolrEntityProcessor substitutes variables only once in child entities
[ https://issues.apache.org/jira/browse/SOLR-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895948#comment-13895948 ] Erick Erickson commented on SOLR-5190: -- bq: Is there any chance, this will be merged to branch lucene_solr_4_3 / lucene_solr_4_4 Probably not. Someone would have to volunteer to be the release manager for, say, a 4.4.1 release or whatever and everyone's time is extremely limited. It would be pretty straight forward for you to check out the code branch for 4.4, apply the patch locally and compile if it's important enough though. Erick SolrEntityProcessor substitutes variables only once in child entities - Key: SOLR-5190 URL: https://issues.apache.org/jira/browse/SOLR-5190 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.4 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 4.5, 5.0 Attachments: SOLR-5190.patch As noted by users on the mailing list and elsewhere, SolrEntityProcessor cannot be used in a child entity because it substitutes variables only once. http://www.mail-archive.com/solr-user@lucene.apache.org/msg88002.html http://stackoverflow.com/questions/15734308/solrentityprocessor-is-called-only-once-for-sub-entities?lq=1 SOLR-3336 attempted to fix the problem by moving variable substitution to the doQuery method but that fix is not complete because the doQuery method is called only once. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5441) Decouple DocIdSet from OpenBitSet and FixedBitSet
[
https://issues.apache.org/jira/browse/LUCENE-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5441:
--
Attachment: LUCENE-5441.patch
Attached is a quick patch (only lucene/core compiles successfully), to show how
it could look like.
The bigger problems are (as expected) in the join and grouping modules. Solr is
mostly unaffected, because it does not really use or implement Lucene filters.
Decouple DocIdSet from OpenBitSet and FixedBitSet
-
Key: LUCENE-5441
URL: https://issues.apache.org/jira/browse/LUCENE-5441
Project: Lucene - Core
Issue Type: Task
Components: core/other
Affects Versions: 4.6.1
Reporter: Uwe Schindler
Fix For: 5.0
Attachments: LUCENE-5441.patch
Back from the times of Lucene 2.4 when DocIdSet was introduced, we somehow
kept the stupid filters can return a BitSet directly in the code. So lots
of Filters return just FixedBitSet, because this is the superclass (ideally
interface) of FixedBitSet.
We should decouple that and *not* implement that abstract interface directly
by FixedBitSet. This leads to bugs e.g. in BlockJoin, because it used Filters
in a wrong way, just because it was always returning Bitsets. But some
filters actually don't do this.
I propose to let FixedBitSet (only in trunk, because that a major backwards
break) just have a method {{asDocIdSet()}}, that returns an anonymous
instance of DocIdSet: bits() returns the FixedBitSet itsself, iterator()
returns a new Iterator (like it always did) and the cost/cacheable methods
return static values.
Filters in trunk would need to be changed like that:
{code:java}
FixedBitSet bits =
...
return bits;
{code}
gets:
{code:java}
FixedBitSet bits =
...
return bits.asDocIdSet();
{code}
As this methods returns an anonymous DocIdSet, calling code can no longer
rely or check if the implementation behind is a FixedBitSet.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5441) Decouple DocIdSet from OpenBitSet and FixedBitSet
[
https://issues.apache.org/jira/browse/LUCENE-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895952#comment-13895952
]
Uwe Schindler commented on LUCENE-5441:
---
bq. It should then be pretty easy to implement a DocSet/DocIdSet backed by a
FixedBitSet?
Very easy, see the last patch :-) I am at the moment not really happy about the
and/or/xor(DocIdSetIterator) methods...
Decouple DocIdSet from OpenBitSet and FixedBitSet
-
Key: LUCENE-5441
URL: https://issues.apache.org/jira/browse/LUCENE-5441
Project: Lucene - Core
Issue Type: Task
Components: core/other
Affects Versions: 4.6.1
Reporter: Uwe Schindler
Fix For: 5.0
Attachments: LUCENE-5441.patch
Back from the times of Lucene 2.4 when DocIdSet was introduced, we somehow
kept the stupid filters can return a BitSet directly in the code. So lots
of Filters return just FixedBitSet, because this is the superclass (ideally
interface) of FixedBitSet.
We should decouple that and *not* implement that abstract interface directly
by FixedBitSet. This leads to bugs e.g. in BlockJoin, because it used Filters
in a wrong way, just because it was always returning Bitsets. But some
filters actually don't do this.
I propose to let FixedBitSet (only in trunk, because that a major backwards
break) just have a method {{asDocIdSet()}}, that returns an anonymous
instance of DocIdSet: bits() returns the FixedBitSet itsself, iterator()
returns a new Iterator (like it always did) and the cost/cacheable methods
return static values.
Filters in trunk would need to be changed like that:
{code:java}
FixedBitSet bits =
...
return bits;
{code}
gets:
{code:java}
FixedBitSet bits =
...
return bits.asDocIdSet();
{code}
As this methods returns an anonymous DocIdSet, calling code can no longer
rely or check if the implementation behind is a FixedBitSet.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5441) Decouple DocIdSet from OpenBitSet and FixedBitSet
[
https://issues.apache.org/jira/browse/LUCENE-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895957#comment-13895957
]
Uwe Schindler commented on LUCENE-5441:
---
Another option to do this would be to create a separate class instead of the
anonymous DocIdSet implementation: {{FixedBitSetDocIdSet}}. The
{{asDocIdSet()}} method is just for easy-use. It could simply wrap using that
class. In this case, the crazy generics in my patch (see TestFixedBitSet
extends-clause) could use the {{FixedBitSetDocIdSet}} in its generics.
Decouple DocIdSet from OpenBitSet and FixedBitSet
-
Key: LUCENE-5441
URL: https://issues.apache.org/jira/browse/LUCENE-5441
Project: Lucene - Core
Issue Type: Task
Components: core/other
Affects Versions: 4.6.1
Reporter: Uwe Schindler
Fix For: 5.0
Attachments: LUCENE-5441.patch
Back from the times of Lucene 2.4 when DocIdSet was introduced, we somehow
kept the stupid filters can return a BitSet directly in the code. So lots
of Filters return just FixedBitSet, because this is the superclass (ideally
interface) of FixedBitSet.
We should decouple that and *not* implement that abstract interface directly
by FixedBitSet. This leads to bugs e.g. in BlockJoin, because it used Filters
in a wrong way, just because it was always returning Bitsets. But some
filters actually don't do this.
I propose to let FixedBitSet (only in trunk, because that a major backwards
break) just have a method {{asDocIdSet()}}, that returns an anonymous
instance of DocIdSet: bits() returns the FixedBitSet itsself, iterator()
returns a new Iterator (like it always did) and the cost/cacheable methods
return static values.
Filters in trunk would need to be changed like that:
{code:java}
FixedBitSet bits =
...
return bits;
{code}
gets:
{code:java}
FixedBitSet bits =
...
return bits.asDocIdSet();
{code}
As this methods returns an anonymous DocIdSet, calling code can no longer
rely or check if the implementation behind is a FixedBitSet.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5190) SolrEntityProcessor substitutes variables only once in child entities
[ https://issues.apache.org/jira/browse/SOLR-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895959#comment-13895959 ] Dominik Siebel commented on SOLR-5190: -- [~steamedcotton] Already did (forked github mirror). Just thought it would be nice to have it in the upstream. Thanks for the reply! SolrEntityProcessor substitutes variables only once in child entities - Key: SOLR-5190 URL: https://issues.apache.org/jira/browse/SOLR-5190 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.4 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 4.5, 5.0 Attachments: SOLR-5190.patch As noted by users on the mailing list and elsewhere, SolrEntityProcessor cannot be used in a child entity because it substitutes variables only once. http://www.mail-archive.com/solr-user@lucene.apache.org/msg88002.html http://stackoverflow.com/questions/15734308/solrentityprocessor-is-called-only-once-for-sub-entities?lq=1 SOLR-3336 attempted to fix the problem by moving variable substitution to the doQuery method but that fix is not complete because the doQuery method is called only once. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5441) Decouple DocIdSet from OpenBitSet and FixedBitSet
[
https://issues.apache.org/jira/browse/LUCENE-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5441:
--
Attachment: LUCENE-5441.patch
New patch, that makes everything compile and pass tests.
Decouple DocIdSet from OpenBitSet and FixedBitSet
-
Key: LUCENE-5441
URL: https://issues.apache.org/jira/browse/LUCENE-5441
Project: Lucene - Core
Issue Type: Task
Components: core/other
Affects Versions: 4.6.1
Reporter: Uwe Schindler
Fix For: 5.0
Attachments: LUCENE-5441.patch, LUCENE-5441.patch
Back from the times of Lucene 2.4 when DocIdSet was introduced, we somehow
kept the stupid filters can return a BitSet directly in the code. So lots
of Filters return just FixedBitSet, because this is the superclass (ideally
interface) of FixedBitSet.
We should decouple that and *not* implement that abstract interface directly
by FixedBitSet. This leads to bugs e.g. in BlockJoin, because it used Filters
in a wrong way, just because it was always returning Bitsets. But some
filters actually don't do this.
I propose to let FixedBitSet (only in trunk, because that a major backwards
break) just have a method {{asDocIdSet()}}, that returns an anonymous
instance of DocIdSet: bits() returns the FixedBitSet itsself, iterator()
returns a new Iterator (like it always did) and the cost/cacheable methods
return static values.
Filters in trunk would need to be changed like that:
{code:java}
FixedBitSet bits =
...
return bits;
{code}
gets:
{code:java}
FixedBitSet bits =
...
return bits.asDocIdSet();
{code}
As this methods returns an anonymous DocIdSet, calling code can no longer
rely or check if the implementation behind is a FixedBitSet.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5441) Decouple DocIdSet from OpenBitSet and FixedBitSet
[
https://issues.apache.org/jira/browse/LUCENE-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895972#comment-13895972
]
Shai Erera commented on LUCENE-5441:
Yes, a dedicated class, I would call it maybe BitsDocIdSet, is better. And then
we don't need to sugar FBS.asDocIdSet, as it's the same as someone doing
{{DocIdSet docsSet = new BitsDocIdSet(bitset);}}. Then FixedBitSet becomes,
hopefully, fully decoupled from DocIdSet. I will review the patch.
Decouple DocIdSet from OpenBitSet and FixedBitSet
-
Key: LUCENE-5441
URL: https://issues.apache.org/jira/browse/LUCENE-5441
Project: Lucene - Core
Issue Type: Task
Components: core/other
Affects Versions: 4.6.1
Reporter: Uwe Schindler
Fix For: 5.0
Attachments: LUCENE-5441.patch, LUCENE-5441.patch
Back from the times of Lucene 2.4 when DocIdSet was introduced, we somehow
kept the stupid filters can return a BitSet directly in the code. So lots
of Filters return just FixedBitSet, because this is the superclass (ideally
interface) of FixedBitSet.
We should decouple that and *not* implement that abstract interface directly
by FixedBitSet. This leads to bugs e.g. in BlockJoin, because it used Filters
in a wrong way, just because it was always returning Bitsets. But some
filters actually don't do this.
I propose to let FixedBitSet (only in trunk, because that a major backwards
break) just have a method {{asDocIdSet()}}, that returns an anonymous
instance of DocIdSet: bits() returns the FixedBitSet itsself, iterator()
returns a new Iterator (like it always did) and the cost/cacheable methods
return static values.
Filters in trunk would need to be changed like that:
{code:java}
FixedBitSet bits =
...
return bits;
{code}
gets:
{code:java}
FixedBitSet bits =
...
return bits.asDocIdSet();
{code}
As this methods returns an anonymous DocIdSet, calling code can no longer
rely or check if the implementation behind is a FixedBitSet.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-5440: --- Attachment: LUCENE-5440.patch New patch: * All lucene/ code is now cut over to (Long)FixedBitSet, including ChainedFilter. What remains is OBS, test and iterator. I think I'll extract FBS.iterator() to its own class, so that we could optimize in FBS.or() and friends. * OpenBitSetDISI is now unused, not in lucene/ nor solr/. Should I nuke it? * I also moved some code which used FBS copy-constructor to grow an FBS to FBS.ensureCapacity. So now nothing uses the new copy-constructor -- nuke it? I think we can cutover Solr usage of OBS in a separate commit/patch/issue, to make this issue contained. Add LongFixedBitSet and replace usage of OpenBitSet --- Key: LUCENE-5440 URL: https://issues.apache.org/jira/browse/LUCENE-5440 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing more than 2.1B bits. It overcome some issues I've encountered with OpenBitSet, such as the use of set/fastSet as well the implementation of DocIdSet. I'll post a patch shortly and describe it in more detail. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5425) Make creation of FixedBitSet in FacetsCollector overridable
[ https://issues.apache.org/jira/browse/LUCENE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895977#comment-13895977 ] Uwe Schindler commented on LUCENE-5425: --- Hi, unfortunately the methods FixedBitSet.or(DocIdSetIterator) now can no longer use the optimization. We should refactor the anaonymous iterator to be a pkg-private class and change the instanceof checks in the and/or/ methods use that class. Make creation of FixedBitSet in FacetsCollector overridable --- Key: LUCENE-5425 URL: https://issues.apache.org/jira/browse/LUCENE-5425 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.6 Reporter: John Wang Assignee: Shai Erera Fix For: 5.0, 4.7 Attachments: LUCENE-5425.patch, facetscollector.patch, facetscollector.patch, fixbitset.patch In FacetsCollector, creation of bits in MatchingDocs are allocated per query. For large indexes where maxDocs are large creating a bitset of maxDoc bits will be expensive and would great a lot of garbage. Attached patch is to allow for this allocation customizable while maintaining current behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5425) Make creation of FixedBitSet in FacetsCollector overridable
[ https://issues.apache.org/jira/browse/LUCENE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13895977#comment-13895977 ] Uwe Schindler edited comment on LUCENE-5425 at 2/9/14 6:46 PM: --- Hi, unfortunately the methods FixedBitSet.or(DocIdSetIterator) now can no longer use the optimization. We should refactor the anaonymous iterator to be a pkg-private class and change the instanceof checks in the and/or/ methods use that class. BooleanFilter and ChainedFilter make heavy use of this opto!!! was (Author: thetaphi): Hi, unfortunately the methods FixedBitSet.or(DocIdSetIterator) now can no longer use the optimization. We should refactor the anaonymous iterator to be a pkg-private class and change the instanceof checks in the and/or/ methods use that class. Make creation of FixedBitSet in FacetsCollector overridable --- Key: LUCENE-5425 URL: https://issues.apache.org/jira/browse/LUCENE-5425 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.6 Reporter: John Wang Assignee: Shai Erera Fix For: 5.0, 4.7 Attachments: LUCENE-5425.patch, facetscollector.patch, facetscollector.patch, fixbitset.patch In FacetsCollector, creation of bits in MatchingDocs are allocated per query. For large indexes where maxDocs are large creating a bitset of maxDoc bits will be expensive and would great a lot of garbage. Attached patch is to allow for this allocation customizable while maintaining current behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5710) Migrate collection command does not handle not finding a shard leader well
Shalin Shekhar Mangar created SOLR-5710: --- Summary: Migrate collection command does not handle not finding a shard leader well Key: SOLR-5710 URL: https://issues.apache.org/jira/browse/SOLR-5710 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 5.0, 4.7 Mark Miller reported SOLR-5644 on the splitshard action. The 'migrate' action also suffers from the same bug and uses replica.getLeader instead of the more robust zkStateReader.getLeaderRetry method. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-5440: --- Attachment: LUCENE-5440.patch Added a FixedBitSetIterator class and optimization in or/and etc. to do instanceof checks. Also nuked the copy-constructors - if someone wants to grow, he can use ensureCapacity. And I don't think shrinking a bitset is a good enough usecase to keep the ctor (it was anyway not entirely safe, as it didn't turn off the unused bits in the last word...). I think this is ready. If there are no objections, I'd like to commit this tomorrow and proceed w/ cutting over Solr to FBS/LFBS as well. Add LongFixedBitSet and replace usage of OpenBitSet --- Key: LUCENE-5440 URL: https://issues.apache.org/jira/browse/LUCENE-5440 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing more than 2.1B bits. It overcome some issues I've encountered with OpenBitSet, such as the use of set/fastSet as well the implementation of DocIdSet. I'll post a patch shortly and describe it in more detail. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5710) Migrate collection command does not handle not finding a shard leader well
[ https://issues.apache.org/jira/browse/SOLR-5710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896010#comment-13896010 ] ASF subversion and git services commented on SOLR-5710: --- Commit 1566385 from sha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1566385 ] SOLR-5710: Migrate collection command does not handle not finding a shard leader well Migrate collection command does not handle not finding a shard leader well -- Key: SOLR-5710 URL: https://issues.apache.org/jira/browse/SOLR-5710 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 5.0, 4.7 Mark Miller reported SOLR-5644 on the splitshard action. The 'migrate' action also suffers from the same bug and uses replica.getLeader instead of the more robust zkStateReader.getLeaderRetry method. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5710) Migrate collection command does not handle not finding a shard leader well
[ https://issues.apache.org/jira/browse/SOLR-5710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-5710. - Resolution: Fixed Migrate collection command does not handle not finding a shard leader well -- Key: SOLR-5710 URL: https://issues.apache.org/jira/browse/SOLR-5710 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 5.0, 4.7 Mark Miller reported SOLR-5644 on the splitshard action. The 'migrate' action also suffers from the same bug and uses replica.getLeader instead of the more robust zkStateReader.getLeaderRetry method. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5710) Migrate collection command does not handle not finding a shard leader well
[ https://issues.apache.org/jira/browse/SOLR-5710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896011#comment-13896011 ] ASF subversion and git services commented on SOLR-5710: --- Commit 1566387 from sha...@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1566387 ] SOLR-5710: Migrate collection command does not handle not finding a shard leader well Migrate collection command does not handle not finding a shard leader well -- Key: SOLR-5710 URL: https://issues.apache.org/jira/browse/SOLR-5710 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.7 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 5.0, 4.7 Mark Miller reported SOLR-5644 on the splitshard action. The 'migrate' action also suffers from the same bug and uses replica.getLeader instead of the more robust zkStateReader.getLeaderRetry method. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5695) Add support for BlendedInfixSuggester in Solr
[ https://issues.apache.org/jira/browse/SOLR-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896020#comment-13896020 ] ASF subversion and git services commented on SOLR-5695: --- Commit 1566389 from [~areek] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1566389 ] SOLR-5695: Make best effort to clean up suggester index Add support for BlendedInfixSuggester in Solr - Key: SOLR-5695 URL: https://issues.apache.org/jira/browse/SOLR-5695 Project: Solr Issue Type: Improvement Components: SearchComponents - other Reporter: Areek Zillur Assignee: Areek Zillur Fix For: 5.0, 4.7 Attachments: SOLR-5695.patch It would be nice to add support for the new BlendedInfixSuggester in Lucene to Solr. The new suggester is similar to AnalyzingInfixSuggester but enables changing the weight of suggesters at query-time depending on the position of the first matching word. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5695) Add support for BlendedInfixSuggester in Solr
[ https://issues.apache.org/jira/browse/SOLR-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896019#comment-13896019 ] ASF subversion and git services commented on SOLR-5695: --- Commit 1566388 from [~areek] in branch 'dev/trunk' [ https://svn.apache.org/r1566388 ] SOLR-5695: Make best effort to clean up suggester index Add support for BlendedInfixSuggester in Solr - Key: SOLR-5695 URL: https://issues.apache.org/jira/browse/SOLR-5695 Project: Solr Issue Type: Improvement Components: SearchComponents - other Reporter: Areek Zillur Assignee: Areek Zillur Fix For: 5.0, 4.7 Attachments: SOLR-5695.patch It would be nice to add support for the new BlendedInfixSuggester in Lucene to Solr. The new suggester is similar to AnalyzingInfixSuggester but enables changing the weight of suggesters at query-time depending on the position of the first matching word. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896025#comment-13896025 ] Shawn Heisey commented on LUCENE-5440: -- Is there any way to deprecate but keep FixedBitSet while moving to IntFixedBitSet? A simple 'extends' isn't possible unless the final modifier is removed, and I think doing it any other way would lead to breakage. Add LongFixedBitSet and replace usage of OpenBitSet --- Key: LUCENE-5440 URL: https://issues.apache.org/jira/browse/LUCENE-5440 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing more than 2.1B bits. It overcome some issues I've encountered with OpenBitSet, such as the use of set/fastSet as well the implementation of DocIdSet. I'll post a patch shortly and describe it in more detail. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896024#comment-13896024
]
Mark Miller commented on SOLR-5476:
---
To sum up an offline conversation Noble and I had about this:
I'm not happy with the approach, I think it's dangerous, and I'm worried about
making more and more of these types of exceptions.
However, I will withdraw my -1 on it if the testing is significantly beefed up
and it can be proved the current approach is usually not going to screw you. I
think the current test is an absolute minimum test and it has regularly failed
on jenkins (and for me locally even more fequently) since it was committed.
We also agreed on a JIRA issue to come up with a better approach at some point.
I also think we need to add some defensive programming. If we try and remove a
queue item that is not there, we should assume another overseer already ate it
rather than letting the Overseer thread die.
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5704) solr.xml coreNodeDirectory is ignored when creating new cores via REST(ish) apis
[
https://issues.apache.org/jira/browse/SOLR-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Woodward updated SOLR-5704:
Attachment: SOLR-5704.patch
So the problem here is that when a CoreDescriptor gets a relative instance dir,
it always resolves that against solr home. This patch updates it to check for
a coreRootDirectory first.
solr.xml coreNodeDirectory is ignored when creating new cores via REST(ish)
apis
Key: SOLR-5704
URL: https://issues.apache.org/jira/browse/SOLR-5704
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1
Environment: x86_64 Linux
x86_64 Sun Java 7_u21
Reporter: Jesse Sipprell
Assignee: Alan Woodward
Priority: Minor
Labels: solr.xml
Attachments: SOLR-5704.patch
New style core.properties auto-configuration works correctly at startup
when {{$\{coreRootDirectory\}}} is specified in {{$\{solr.home\}/solr.xml}},
however it does not work if a core is later created dynamically via either
(indirectly) the collection API or (directly) the core API.
Core creation is always attempted in {{$\{solr.home\}}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896039#comment-13896039 ] Shai Erera commented on LUCENE-5440: I don't think we should deprecate anything. We can simply rename it - it's an internal class... If we rename it, I think we should just rename it to Int/LongBitSet. The word Fixed should not be there, I doubt if it was if we didn't have OpenBitSet. That that it's fixed is a given, and documented. I don't mind renaming it, as I said it's just a rote rename. Perhaps I should name the Long bit set LongBitSet (remove Fixed), to avoid renames in the future. Add LongFixedBitSet and replace usage of OpenBitSet --- Key: LUCENE-5440 URL: https://issues.apache.org/jira/browse/LUCENE-5440 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing more than 2.1B bits. It overcome some issues I've encountered with OpenBitSet, such as the use of set/fastSet as well the implementation of DocIdSet. I'll post a patch shortly and describe it in more detail. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896045#comment-13896045 ] Uwe Schindler commented on LUCENE-5440: --- The class is definitely not internal only. Almost every filter I know of outside of Lucene uses it. I disahree with renaming it before Lucene 5. Add LongFixedBitSet and replace usage of OpenBitSet --- Key: LUCENE-5440 URL: https://issues.apache.org/jira/browse/LUCENE-5440 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing more than 2.1B bits. It overcome some issues I've encountered with OpenBitSet, such as the use of set/fastSet as well the implementation of DocIdSet. I'll post a patch shortly and describe it in more detail. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5376) Add a demo search server
[ https://issues.apache.org/jira/browse/LUCENE-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896081#comment-13896081 ] ASF subversion and git services commented on LUCENE-5376: - Commit 1566454 from [~mikemccand] in branch 'dev/branches/lucene5376' [ https://svn.apache.org/r1566454 ] LUCENE-5376: sync trunk Add a demo search server Key: LUCENE-5376 URL: https://issues.apache.org/jira/browse/LUCENE-5376 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: lucene-demo-server.tgz I think it'd be useful to have a demo search server for Lucene. Rather than being fully featured, like Solr, it would be minimal, just wrapping the existing Lucene modules to show how you can make use of these features in a server setting. The purpose is to demonstrate how one can build a minimal search server on top of APIs like SearchManager, SearcherLifetimeManager, etc. This is also useful for finding rough edges / issues in Lucene's APIs that make building a server unnecessarily hard. I don't think it should have back compatibility promises (except Lucene's index back compatibility), so it's free to improve as Lucene's APIs change. As a starting point, I'll post what I built for the eating your own dog food search app for Lucene's Solr's jira issues http://jirasearch.mikemccandless.com (blog: http://blog.mikemccandless.com/2013/05/eating-dog-food-with-lucene.html ). It uses Netty to expose basic indexing searching APIs via JSON, but it's very rough (lots nocommits). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896085#comment-13896085 ] ASF subversion and git services commented on SOLR-3854: --- Commit 1566456 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1566456 ] SOLR-3854: SSL support for SolrCloud SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896086#comment-13896086 ] Mark Miller commented on SOLR-3854: --- I just committed an initial pass to trunk. Since we are just working out tests here, it will be easier to collaborate this way - patch is getting unwieldy. The latest has SSL working for almost all tests randomly, if possible. Some tests are excluded for various reasons. It's a huge expansion in our coverage though. Currently, we don't use the client auth setting. Perhaps that can be improved by someone that understands it better than I. I'd have to dig first. [~sdavids], I'll leave this open in the case you have any further patches in you. Likewise, let me know if everything looks okay to you. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896087#comment-13896087 ] Mark Miller commented on SOLR-3854: --- https://github.com/apache/lucene-solr/commit/e400b48a7e778d17678311b1d48f9fcb7e741b0d SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[
https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896088#comment-13896088
]
Steve Davids commented on SOLR-3854:
Awesome, will take a little bit more of a deep-dive. One thing I noticed right
away though, what's the reason for adding {code}str
name=urlScheme${urlScheme:}/str{code} throughout the various solr.xml
files? That shouldn't be necessary with the patch.
SolrCloud does not work with https
--
Key: SOLR-3854
URL: https://issues.apache.org/jira/browse/SOLR-3854
Project: Solr
Issue Type: Bug
Reporter: Sami Siren
Assignee: Mark Miller
Fix For: 5.0, 4.7
Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch,
SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch,
SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch
There are a few places in current codebase that assume http is used. This
prevents using https when running solr in cloud mode.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896091#comment-13896091 ] Mark Miller commented on SOLR-3854: --- Yeah, it's needed - not all tests are solrcloud tests or have zookeeper involved. Those tests now also use SSL randomly and do distrib searches and need to turn on the https scheme. One of the base SolrCloud tests will clear that system property. Probably better if that was cleared randomly for better coverage. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5652) Heisenbug in DistribCursorPagingTest: walk already seen ...
[
https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896104#comment-13896104
]
Steve Rowe commented on SOLR-5652:
--
bq. I've attached another patch that also skips sorting on dv fields.
On Linux, on trunk with this patch, I ran 1000 trials of {{ant
-Dtests.class=\*Cursor\* test}} in a bash loop (well, three concurrent bash
loops), and there were no failures. I'd call this one licked.
Heisenbug in DistribCursorPagingTest: walk already seen ...
-
Key: SOLR-5652
URL: https://issues.apache.org/jira/browse/SOLR-5652
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Attachments: 129.log, 372.log,
SOLR-5652-dont-sort-on-any-dv-fields-when-codec-doesnt-support-missing-dvs.patch,
SOLR-5652.codec.skip.dv.patch, SOLR-5652.nocommit.patch, SOLR-5652.patch,
bin_dv.post-patch.log.txt,
jenkins.thetaphi.de_Lucene-Solr-4.x-MacOSX_1200.log.txt,
jenkins.thetaphi.de_Lucene-Solr-4.x-MacOSX_1217.log.txt,
str_dv.post-patch.log.txt
Several times now, Uwe's jenkins has encountered a walk already seen ...
assertion failure from DistribCursorPagingTest that I've been unable to
fathom, let alone reproduce (although sarowe was able to trigger a similar,
non-reproducible seed, failure on his machine)
Using this as a tracking issue to try and make sense of it.
Summary of things noticed so far:
* So far only seen on http://jenkins.thetaphi.de sarowe's mac
* So far seen on MacOSX and Linux
* So far seen on branch 4x and trunk
* So far seen on Java6, Java7, and Java8
* fails occured in first block of randomized testing:
** we've indexed a small number of randomized docs
** we're explicitly looping over every field and sorting in both directions
* fails were sorting on one of the \*_dv_last or \*_dv_first fields
(docValues=true, either sortMissingLast=true OR sortMissingFirst=true)
** for desc sorts, sort on same field asc has worked fine just before this
(fields are in arbitrary order, but asc always tried before desc)
** sorting on some other random fields has sometimes been tried before this
and worked
(specifics of each failure seen in the wild recorded in comments)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5704) solr.xml coreNodeDirectory is ignored when creating new cores via REST(ish) apis
[
https://issues.apache.org/jira/browse/SOLR-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896118#comment-13896118
]
Jesse Sipprell commented on SOLR-5704:
--
I've tested out the attached patch and it seems to work as expected; at least
with SPLITSHARD.
Thanks,
Jesse
solr.xml coreNodeDirectory is ignored when creating new cores via REST(ish)
apis
Key: SOLR-5704
URL: https://issues.apache.org/jira/browse/SOLR-5704
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1
Environment: x86_64 Linux
x86_64 Sun Java 7_u21
Reporter: Jesse Sipprell
Assignee: Alan Woodward
Priority: Minor
Labels: solr.xml
Attachments: SOLR-5704.patch
New style core.properties auto-configuration works correctly at startup
when {{$\{coreRootDirectory\}}} is specified in {{$\{solr.home\}/solr.xml}},
however it does not work if a core is later created dynamically via either
(indirectly) the collection API or (directly) the core API.
Core creation is always attempted in {{$\{solr.home\}}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896125#comment-13896125 ] ASF subversion and git services commented on SOLR-3854: --- Commit 1566483 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1566483 ] SOLR-3854: Boost test timeouts - SSL can be slower. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5585) The Collections API timeout is too low at 1 minute.
[ https://issues.apache.org/jira/browse/SOLR-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896131#comment-13896131 ] ASF subversion and git services commented on SOLR-5585: --- Commit 1566485 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1566485 ] SOLR-5585: Raise Collections API timeout to 3 minutes from one minute. The Collections API timeout is too low at 1 minute. --- Key: SOLR-5585 URL: https://issues.apache.org/jira/browse/SOLR-5585 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5585) The Collections API timeout is too low at 1 minute.
[ https://issues.apache.org/jira/browse/SOLR-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896134#comment-13896134 ] ASF subversion and git services commented on SOLR-5585: --- Commit 1566486 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1566486 ] SOLR-5585: Raise Collections API timeout to 3 minutes from one minute. The Collections API timeout is too low at 1 minute. --- Key: SOLR-5585 URL: https://issues.apache.org/jira/browse/SOLR-5585 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5585) The Collections API timeout is too low at 1 minute.
[ https://issues.apache.org/jira/browse/SOLR-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5585. --- Resolution: Fixed The Collections API timeout is too low at 1 minute. --- Key: SOLR-5585 URL: https://issues.apache.org/jira/browse/SOLR-5585 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5711) Build Lucene Javadocs as a standalone artifact for Solr users
Alexandre Rafalovitch created SOLR-5711: --- Summary: Build Lucene Javadocs as a standalone artifact for Solr users Key: SOLR-5711 URL: https://issues.apache.org/jira/browse/SOLR-5711 Project: Solr Issue Type: Wish Components: Build, documentation Affects Versions: 4.6.1 Reporter: Alexandre Rafalovitch Priority: Minor Fix For: 4.7 Solr relies on a lot of Lucene packages. Some of the classes (e.g. Tokenizers) have a lot of documentation in the Javadoc. However, the JavaDoc shipped with Solr only covers Solr specific classes. And full Lucene download is rather large (50M) to get them just for JavaDocs. It would be useful to have a separate download of just Lucene Javadocs for those people who want/need to work offline and want to have all the relevant documentation. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5425) Make creation of FixedBitSet in FacetsCollector overridable
[ https://issues.apache.org/jira/browse/LUCENE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896149#comment-13896149 ] Lei Wang commented on LUCENE-5425: -- Looks like we should be able to replace the impl of OpenBitSetIterator with the one Shai added in the FixedBitSet. The only missing data is the numBits, but it's optional. And at the same time, any code that is using the will be benefit from this. Make creation of FixedBitSet in FacetsCollector overridable --- Key: LUCENE-5425 URL: https://issues.apache.org/jira/browse/LUCENE-5425 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.6 Reporter: John Wang Assignee: Shai Erera Fix For: 5.0, 4.7 Attachments: LUCENE-5425.patch, facetscollector.patch, facetscollector.patch, fixbitset.patch In FacetsCollector, creation of bits in MatchingDocs are allocated per query. For large indexes where maxDocs are large creating a bitset of maxDoc bits will be expensive and would great a lot of garbage. Attached patch is to allow for this allocation customizable while maintaining current behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5425) Make creation of FixedBitSet in FacetsCollector overridable
[ https://issues.apache.org/jira/browse/LUCENE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lei Wang updated LUCENE-5425: - Attachment: openbitsetiter.patch Faster OpenBitSetIterator Make creation of FixedBitSet in FacetsCollector overridable --- Key: LUCENE-5425 URL: https://issues.apache.org/jira/browse/LUCENE-5425 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.6 Reporter: John Wang Assignee: Shai Erera Fix For: 5.0, 4.7 Attachments: LUCENE-5425.patch, facetscollector.patch, facetscollector.patch, fixbitset.patch, openbitsetiter.patch In FacetsCollector, creation of bits in MatchingDocs are allocated per query. For large indexes where maxDocs are large creating a bitset of maxDoc bits will be expensive and would great a lot of garbage. Attached patch is to allow for this allocation customizable while maintaining current behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch
[
https://issues.apache.org/jira/browse/SOLR-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896174#comment-13896174
]
ASF subversion and git services commented on SOLR-5608:
---
Commit 1566492 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1566492 ]
SOLR-5608: Add short poll to test.
Frequently reproducible failures in
CollectionsAPIDistributedZkTest#testDistribSearch
-
Key: SOLR-5608
URL: https://issues.apache.org/jira/browse/SOLR-5608
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.7
Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64
GNU/Linux
java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
Fix For: 5.0, 4.7
Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt,
SOLR-5608-failure3.txt, SOLR-5608-lshw.txt
This is what looks like the relevant piece of the failure.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 179s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
This jenkins failure looks like it may be similar:
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch
[
https://issues.apache.org/jira/browse/SOLR-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896175#comment-13896175
]
ASF subversion and git services commented on SOLR-5608:
---
Commit 1566493 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1566493 ]
SOLR-5608: Add short poll to test.
Frequently reproducible failures in
CollectionsAPIDistributedZkTest#testDistribSearch
-
Key: SOLR-5608
URL: https://issues.apache.org/jira/browse/SOLR-5608
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.7
Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64
GNU/Linux
java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
Fix For: 5.0, 4.7
Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt,
SOLR-5608-failure3.txt, SOLR-5608-lshw.txt
This is what looks like the relevant piece of the failure.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 179s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
This jenkins failure looks like it may be similar:
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5425) Make creation of FixedBitSet in FacetsCollector overridable
[ https://issues.apache.org/jira/browse/LUCENE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896200#comment-13896200 ] Shai Erera commented on LUCENE-5425: Uwe, I added an explicit FixedBitSetIterator and the optimization in LUCENE-5440. Lei, on LUCENE-5440 I'm moving all the code to use FixedBitSet instead of OpenBitSet and therefore it will use the new iterator by default. The intention is to get rid of OpenBitSet and accompanying classes. Make creation of FixedBitSet in FacetsCollector overridable --- Key: LUCENE-5425 URL: https://issues.apache.org/jira/browse/LUCENE-5425 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.6 Reporter: John Wang Assignee: Shai Erera Fix For: 5.0, 4.7 Attachments: LUCENE-5425.patch, facetscollector.patch, facetscollector.patch, fixbitset.patch, openbitsetiter.patch In FacetsCollector, creation of bits in MatchingDocs are allocated per query. For large indexes where maxDocs are large creating a bitset of maxDoc bits will be expensive and would great a lot of garbage. Attached patch is to allow for this allocation customizable while maintaining current behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896202#comment-13896202 ] Shai Erera commented on LUCENE-5440: Fair enough, I will rename the Long version to LongBitSet then, to avoid future renames. Add LongFixedBitSet and replace usage of OpenBitSet --- Key: LUCENE-5440 URL: https://issues.apache.org/jira/browse/LUCENE-5440 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing more than 2.1B bits. It overcome some issues I've encountered with OpenBitSet, such as the use of set/fastSet as well the implementation of DocIdSet. I'll post a patch shortly and describe it in more detail. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-5440: --- Attachment: LUCENE-5440.patch Patch renames to LongBitSet. Add LongFixedBitSet and replace usage of OpenBitSet --- Key: LUCENE-5440 URL: https://issues.apache.org/jira/browse/LUCENE-5440 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing more than 2.1B bits. It overcome some issues I've encountered with OpenBitSet, such as the use of set/fastSet as well the implementation of DocIdSet. I'll post a patch shortly and describe it in more detail. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3459) Change ChainedFilter to use FixedBitSet
[ https://issues.apache.org/jira/browse/LUCENE-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-3459. Resolution: Duplicate Fix Version/s: (was: 4.7) ChainedFilter was changed to use FixedBitSet on LUCENE-5440. Change ChainedFilter to use FixedBitSet --- Key: LUCENE-3459 URL: https://issues.apache.org/jira/browse/LUCENE-3459 Project: Lucene - Core Issue Type: Task Components: modules/other Affects Versions: 3.4, 4.0-ALPHA Reporter: Uwe Schindler Assignee: Uwe Schindler ChainedFilter also uses OpenBitSet(DISI) at the moment. It should also be changed to use FixedBitSet. There are two issues: - It exposes sometimes OpenBitSetDISI to it's public API - we should remove those methods like in BooleanFilter and break backwards - It allows a XOR operation. This is not yet supported by FixedBitSet, but it's easy to add (like for BooleanFilter). On the other hand, this XOR operation is bogus, as it may mark documents in the BitSet that are deleted, breaking new features like applying Filters down-low (LUCENE-1536). We should remove the XOR operation maybe or force it to use IR.validDocs() (trunk) or IR.isDeleted() -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5425) Make creation of FixedBitSet in FacetsCollector overridable
[ https://issues.apache.org/jira/browse/LUCENE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896217#comment-13896217 ] Lei Wang commented on LUCENE-5425: -- oh cool! that patch looks better! Make creation of FixedBitSet in FacetsCollector overridable --- Key: LUCENE-5425 URL: https://issues.apache.org/jira/browse/LUCENE-5425 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.6 Reporter: John Wang Assignee: Shai Erera Fix For: 5.0, 4.7 Attachments: LUCENE-5425.patch, facetscollector.patch, facetscollector.patch, fixbitset.patch, openbitsetiter.patch In FacetsCollector, creation of bits in MatchingDocs are allocated per query. For large indexes where maxDocs are large creating a bitset of maxDoc bits will be expensive and would great a lot of garbage. Attached patch is to allow for this allocation customizable while maintaining current behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Davids updated SOLR-3854: --- Attachment: SOLR-3854v2.patch Attached a new patch from trunk that allows the test harness to perform two-way SSL handshakes, the two-way SSL will now be randomly selected during test runs. Also, cleaned up some of the code by breaking out the SSLConfig into a separate class. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854v2.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1314 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1314/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.rest.schema.TestSchemaVersionResource Error Message: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 10,620,288 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 10,652,992 bytes, protected static org.apache.solr.util.RestTestHarness org.apache.solr.util.RestTestBase.restTestHarness - 448 bytes, private static java.util.regex.Pattern org.apache.solr.SolrTestCaseJ4.nonEscapedSingleQuotePattern - 376 bytes, private static java.io.File org.apache.solr.SolrTestCaseJ4.TEST_KEYSTORE - 352 bytes, protected static volatile org.apache.solr.client.solrj.embedded.JettySolrRunner$SSLConfig org.apache.solr.SolrTestCaseJ4.sslConfig - 328 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 312 bytes, private static java.util.regex.Pattern org.apache.solr.SolrTestCaseJ4.escapedSingleQuotePattern - 232 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 72 bytes, public static java.lang.String org.apache.solr.SolrJettyTestBase.context Stack Trace: junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 10,620,288 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 10,652,992 bytes, protected static org.apache.solr.util.RestTestHarness org.apache.solr.util.RestTestBase.restTestHarness - 448 bytes, private static java.util.regex.Pattern org.apache.solr.SolrTestCaseJ4.nonEscapedSingleQuotePattern - 376 bytes, private static java.io.File org.apache.solr.SolrTestCaseJ4.TEST_KEYSTORE - 352 bytes, protected static volatile org.apache.solr.client.solrj.embedded.JettySolrRunner$SSLConfig org.apache.solr.SolrTestCaseJ4.sslConfig - 328 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 312 bytes, private static java.util.regex.Pattern org.apache.solr.SolrTestCaseJ4.escapedSingleQuotePattern - 232 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 72 bytes, public static java.lang.String org.apache.solr.SolrJettyTestBase.context at __randomizedtesting.SeedInfo.seed([7B9C397932CFAC4F]:0) at com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:127) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:744) Build Log: [...truncated 11050 lines...] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaVersionResource [junit4] 2 3626786 T11023 oas.SolrTestCaseJ4.getSSLConfig Randomized ssl (true) and clientAuth (false) [junit4] 2 3626787 T11023 oas.SolrTestCaseJ4.initCore initCore [junit4] 2 Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/./solrtest-TestSchemaVersionResource-1392009810165 [junit4] 2 3626789 T11023 oas.SolrTestCaseJ4.initCore initCore end [junit4] 2 3626790 T11023 oejs.Server.doStart jetty-8.1.10.v20130312 [junit4] 2 3626796 T11023 oejus.SslContextFactory.doStart Enabled Protocols [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] [junit4] 2 3626798 T11023 oejs.AbstractConnector.doStart Started SslSelectChannelConnector@127.0.0.1:52569 [junit4] 2 3626810 T11023 oass.SolrDispatchFilter.init SolrDispatchFilter.init() [junit4] 2 3626810 T11023 oasc.SolrResourceLoader.locateSolrHome JNDI not configured for solr (NoInitialContextEx) [junit4] 2 3626810 T11023 oasc.SolrResourceLoader.locateSolrHome using system property solr.solr.home:
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896253#comment-13896253 ] ASF subversion and git services commented on SOLR-3854: --- Commit 1566515 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1566515 ] SOLR-3854: Allows the test harness to perform two-way SSL handshakes, the two-way SSL will now be randomly selected during test runs. Also, cleaned up some of the code by breaking out the SSLConfig into a separate class. Also try and address failing the statics retained check. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854v2.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896255#comment-13896255 ] Mark Miller commented on SOLR-3854: --- Thanks Steve! Great stuff. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854v2.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4777) Handle SliceState in the Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-4777: Attachment: SOLR-4777.patch Patch to the cloud.js and cloud.css files. I couldn't figure out how to add another legend for shard states (well I did but I broke the layout and ended up with an ugly UI). [~steffkes] - I'd appreciate your help! Handle SliceState in the Admin UI - Key: SOLR-4777 URL: https://issues.apache.org/jira/browse/SOLR-4777 Project: Solr Issue Type: Improvement Components: SolrCloud, web gui Affects Versions: 4.3 Reporter: Anshum Gupta Fix For: 4.7 Attachments: SOLR-4777.patch The Solr admin UI as of now does take Slice state into account. We need to have that differentiated. There are three states: # The default is ACTIVE # CONSTRUCTION (used during shard splitting for new sub shards), and # INACTIVE - the parent shard is set to this state after split is complete A slice/shard which is INACTIVE will not accept traffic (i.e. it will re-route traffic to sub shards) even though the nodes inside this shard show up as green. We should show the INACTIVE shards in a different color to highlight this behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1314 - Failure!
I’ve made a change to try and address this. - Mark http://about.me/markrmiller On Feb 10, 2014, at 12:25 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1314/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.rest.schema.TestSchemaVersionResource Error Message: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 10,620,288 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 10,652,992 bytes, protected static org.apache.solr.util.RestTestHarness org.apache.solr.util.RestTestBase.restTestHarness - 448 bytes, private static java.util.regex.Pattern org.apache.solr.SolrTestCaseJ4.nonEscapedSingleQuotePattern - 376 bytes, private static java.io.File org.apache.solr.SolrTestCaseJ4.TEST_KEYSTORE - 352 bytes, protected static volatile org.apache.solr.client.solrj.embedded.JettySolrRunner$SSLConfig org.apache.solr.SolrTestCaseJ4.sslConfig - 328 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 312 bytes, private static java.util.regex.Pattern org.apache.solr.SolrTestCaseJ4.escapedSingleQuotePattern - 232 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 72 bytes, public static java.lang.String org.apache.solr.SolrJettyTestBase.context Stack Trace: junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 10,620,288 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 10,652,992 bytes, protected static org.apache.solr.util.RestTestHarness org.apache.solr.util.RestTestBase.restTestHarness - 448 bytes, private static java.util.regex.Pattern org.apache.solr.SolrTestCaseJ4.nonEscapedSingleQuotePattern - 376 bytes, private static java.io.File org.apache.solr.SolrTestCaseJ4.TEST_KEYSTORE - 352 bytes, protected static volatile org.apache.solr.client.solrj.embedded.JettySolrRunner$SSLConfig org.apache.solr.SolrTestCaseJ4.sslConfig - 328 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 312 bytes, private static java.util.regex.Pattern org.apache.solr.SolrTestCaseJ4.escapedSingleQuotePattern - 232 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName - 72 bytes, public static java.lang.String org.apache.solr.SolrJettyTestBase.context at __randomizedtesting.SeedInfo.seed([7B9C397932CFAC4F]:0) at com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:127) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:744) Build Log: [...truncated 11050 lines...] [junit4] Suite: org.apache.solr.rest.schema.TestSchemaVersionResource [junit4] 2 3626786 T11023 oas.SolrTestCaseJ4.getSSLConfig Randomized ssl (true) and clientAuth (false) [junit4] 2 3626787 T11023 oas.SolrTestCaseJ4.initCore initCore [junit4] 2 Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/./solrtest-TestSchemaVersionResource-1392009810165 [junit4] 2 3626789 T11023 oas.SolrTestCaseJ4.initCore initCore end [junit4] 2 3626790 T11023 oejs.Server.doStart jetty-8.1.10.v20130312 [junit4] 2 3626796 T11023 oejus.SslContextFactory.doStart Enabled Protocols [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] [junit4] 2 3626798 T11023 oejs.AbstractConnector.doStart Started SslSelectChannelConnector@127.0.0.1:52569 [junit4] 2 3626810 T11023 oass.SolrDispatchFilter.init SolrDispatchFilter.init() [junit4] 2 3626810
[jira] [Updated] (SOLR-4777) Handle SliceState in the Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-4777: Description: The Solr admin UI as of now does take Slice state into account. We need to have that differentiated. There are three states: # The default is active # construction (used during shard splitting for new sub shards), # 'recovery' (state is changed from construction to recovery once split is complete and we are waiting for sub-shard replicas to recover from their respective leaders), and # inactive - the parent shard is set to this state after split is complete A slice/shard which is inactive will not accept traffic (i.e. it will re-route traffic to sub shards) even though the nodes inside this shard show up as green. We should show the inactive shards in a different color to highlight this behavior. was: The Solr admin UI as of now does take Slice state into account. We need to have that differentiated. There are three states: # The default is ACTIVE # CONSTRUCTION (used during shard splitting for new sub shards), and # INACTIVE - the parent shard is set to this state after split is complete A slice/shard which is INACTIVE will not accept traffic (i.e. it will re-route traffic to sub shards) even though the nodes inside this shard show up as green. We should show the INACTIVE shards in a different color to highlight this behavior. Handle SliceState in the Admin UI - Key: SOLR-4777 URL: https://issues.apache.org/jira/browse/SOLR-4777 Project: Solr Issue Type: Improvement Components: SolrCloud, web gui Affects Versions: 4.3 Reporter: Anshum Gupta Fix For: 4.7 Attachments: SOLR-4777.patch The Solr admin UI as of now does take Slice state into account. We need to have that differentiated. There are three states: # The default is active # construction (used during shard splitting for new sub shards), # 'recovery' (state is changed from construction to recovery once split is complete and we are waiting for sub-shard replicas to recover from their respective leaders), and # inactive - the parent shard is set to this state after split is complete A slice/shard which is inactive will not accept traffic (i.e. it will re-route traffic to sub shards) even though the nodes inside this shard show up as green. We should show the inactive shards in a different color to highlight this behavior. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896282#comment-13896282 ] Uwe Schindler commented on LUCENE-5440: --- Thanks, I think the @lucene.internal on FixedBitSet is a bug, the javadoc tag should be removed. Without that class it is impossible to external users to implement their own Filter. Not even DocIdBitSet is available anymore, which could be used on top of a java.util.BitSet. Add LongFixedBitSet and replace usage of OpenBitSet --- Key: LUCENE-5440 URL: https://issues.apache.org/jira/browse/LUCENE-5440 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch, LUCENE-5440.patch Spinoff from here: http://lucene.markmail.org/thread/35gw3amo53dsqsqj. I wrote a LongFixedBitSet which behaves like FixedBitSet, only allows managing more than 2.1B bits. It overcome some issues I've encountered with OpenBitSet, such as the use of set/fastSet as well the implementation of DocIdSet. I'll post a patch shortly and describe it in more detail. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-fcs-b128) - Build # 9425 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9425/ Java: 64bit/jdk1.8.0-fcs-b128 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.solr.hadoop.MapReduceIndexerToolArgumentParserTest.testArgsParserHelp Error Message: Conversion = '१' Stack Trace: java.util.UnknownFormatConversionException: Conversion = '१' at __randomizedtesting.SeedInfo.seed([ADC8E16E45C159C:960E2461A33279D1]:0) at java.util.Formatter.checkText(Formatter.java:2579) at java.util.Formatter.parse(Formatter.java:2555) at java.util.Formatter.format(Formatter.java:2501) at java.io.PrintWriter.format(PrintWriter.java:905) at net.sourceforge.argparse4j.helper.TextHelper.printHelp(TextHelper.java:206) at net.sourceforge.argparse4j.internal.ArgumentImpl.printHelp(ArgumentImpl.java:247) at net.sourceforge.argparse4j.internal.ArgumentParserImpl.printArgumentHelp(ArgumentParserImpl.java:253) at net.sourceforge.argparse4j.internal.ArgumentParserImpl.printHelp(ArgumentParserImpl.java:279) at org.apache.solr.hadoop.MapReduceIndexerTool$MyArgumentParser$1.run(MapReduceIndexerTool.java:187) at net.sourceforge.argparse4j.internal.ArgumentImpl.run(ArgumentImpl.java:425) at net.sourceforge.argparse4j.internal.ArgumentParserImpl.processArg(ArgumentParserImpl.java:913) at net.sourceforge.argparse4j.internal.ArgumentParserImpl.parseArgs(ArgumentParserImpl.java:810) at net.sourceforge.argparse4j.internal.ArgumentParserImpl.parseArgs(ArgumentParserImpl.java:683) at net.sourceforge.argparse4j.internal.ArgumentParserImpl.parseArgs(ArgumentParserImpl.java:580) at net.sourceforge.argparse4j.internal.ArgumentParserImpl.parseArgs(ArgumentParserImpl.java:573) at org.apache.solr.hadoop.MapReduceIndexerTool$MyArgumentParser.parseArgs(MapReduceIndexerTool.java:505) at org.apache.solr.hadoop.MapReduceIndexerToolArgumentParserTest.testArgsParserHelp(MapReduceIndexerToolArgumentParserTest.java:194) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
