[jira] [Commented] (SOLR-64) strict hierarchical facets
[ https://issues.apache.org/jira/browse/SOLR-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897613#comment-13897613 ] Ales Perme commented on SOLR-64: Hi Guys. Is there any news on this patch/functionality? It is being pushed from one version to another, regardless it is marked as "Major" and a lot of votes. Is there any viable, performance efficient alternative to this kind of hierarchical facet? Thank you for your reply... > strict hierarchical facets > -- > > Key: SOLR-64 > URL: https://issues.apache.org/jira/browse/SOLR-64 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Yonik Seeley > Fix For: 4.7 > > Attachments: SOLR-64.patch, SOLR-64.patch, SOLR-64.patch, > SOLR-64.patch, SOLR-64_3.1.0.patch > > > Strict Facet Hierarchies... each tag has at most one parent (a tree). -- 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-Windows (32bit/jdk1.8.0-fcs-b128) - Build # 3767 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3767/ Java: 32bit/jdk1.8.0-fcs-b128 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([DED6B40E1C42D981:F17F101FCBCD9685]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused(BasicHttpSolrServerTest.java:159) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) 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 11439 lines...] [junit4] Suite: org.apache.solr.client.solrj.impl.BasicHttpSol
[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-tabpanel&focusedCommentId=13897420#comment-13897420 ] Mark Miller commented on SOLR-3854: --- Thanks Steve - I'll merge back to 4x fairly soon. > 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] [Comment Edited] (SOLR-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
[ https://issues.apache.org/jira/browse/SOLR-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897386#comment-13897386 ] Timothy Potter edited comment on SOLR-5654 at 2/11/14 1:04 AM: --- Basic implementation which depends on my patch for SOLR-5653. It only supports the "solr" format for now and basically uses an adapter to provide a SolrResourceLoader to the existing SynonymFilterFactory which is backed by the managed synonym mappings. Also, I should mention that I'm not thrilled with how I handle ignoreCase changes right now, so will probably clean that up a bit in a subsequent patch. was (Author: tim.potter): Basic implementation which depends on my patch for SOLR-5653. It only supports the "solr" format for now and basically uses an adapter to provide a SolrResourceLoader to the existing SynonymFilterFactory which is backed by the managed synonym mappings. > Create a synonym filter factory that is (re)configurable, and capable of > reporting its configuration, via REST API > -- > > Key: SOLR-5654 > URL: https://issues.apache.org/jira/browse/SOLR-5654 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Reporter: Steve Rowe > Attachments: SOLR-5654.patch > > > A synonym filter factory could be (re)configurable via REST API by > registering with the RESTManager described in SOLR-5653, and then responding > to REST API calls to modify its init params and its synonyms resource file. > Read-only (GET) REST API calls should also be provided, both for init params > and the synonyms resource file. > It should be possible to add/remove/modify one or more entries in the > synonyms resource file. > We should probably use JSON for the REST request body, as is done in the > Schema REST API methods. -- 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-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
[ https://issues.apache.org/jira/browse/SOLR-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-5654: - Attachment: SOLR-5654.patch Basic implementation which depends on my patch for SOLR-5653. It only supports the "solr" format for now and basically uses an adapter to provide a SolrResourceLoader to the existing SynonymFilterFactory which is backed by the managed synonym mappings. > Create a synonym filter factory that is (re)configurable, and capable of > reporting its configuration, via REST API > -- > > Key: SOLR-5654 > URL: https://issues.apache.org/jira/browse/SOLR-5654 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Reporter: Steve Rowe > Attachments: SOLR-5654.patch > > > A synonym filter factory could be (re)configurable via REST API by > registering with the RESTManager described in SOLR-5653, and then responding > to REST API calls to modify its init params and its synonyms resource file. > Read-only (GET) REST API calls should also be provided, both for init params > and the synonyms resource file. > It should be possible to add/remove/modify one or more entries in the > synonyms resource file. > We should probably use JSON for the REST request body, as is done in the > Schema REST API methods. -- 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-5653) Create a RESTManager to provide REST API endpoints for reconfigurable plugins
[
https://issues.apache.org/jira/browse/SOLR-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897383#comment-13897383
]
Mark Miller commented on SOLR-5653:
---
bq. 1. but I didn't see a better way to determine if a core is running in ZK
mode from within the SolrCore object.
You can look at the descriptor for the core, get the corecontainer and call
isZooKeeperAware.
> Create a RESTManager to provide REST API endpoints for reconfigurable plugins
> -
>
> Key: SOLR-5653
> URL: https://issues.apache.org/jira/browse/SOLR-5653
> Project: Solr
> Issue Type: Sub-task
>Reporter: Steve Rowe
> Attachments: SOLR-5653.patch
>
>
> It should be possible to reconfigure Solr plugins' resources and init params
> without directly editing the serialized schema or {{solrconfig.xml}} (see
> Hoss's arguments about this in the context of the schema, which also apply to
> {{solrconfig.xml}}, in the description of SOLR-4658)
> The RESTManager should allow plugins declared in either the schema or in
> {{solrconfig.xml}} to register one or more REST endpoints, one endpoint per
> reconfigurable resource, including init params. To allow for multiple plugin
> instances, registering plugins will need to provide a handle of some form to
> distinguish the instances.
> This RESTManager should also be able to create new instances of plugins that
> it has been configured to allow. The RESTManager will need its own
> serialized configuration to remember these plugin declarations.
> Example endpoints:
> * SynonymFilterFactory
> ** init params: {{/solr/collection1/config/syns/myinstance/options}}
> ** synonyms resource:
> {{/solr/collection1/config/syns/myinstance/synonyms-list}}
> * "/select" request handler
> ** init params: {{/solr/collection1/config/requestHandlers/select/options}}
> We should aim for full CRUD over init params and structured resources. The
> plugins will bear responsibility for handling resource modification requests,
> though we should provide utility methods to make this easy.
> However, since we won't be directly modifying the serialized schema and
> {{solrconfig.xml}}, anything configured in those two places can't be
> invalidated by configuration serialized elsewhere. As a result, it won't be
> possible to remove plugins declared in the serialized schema or
> {{solrconfig.xml}}. Similarly, any init params declared in either place
> won't be modifiable. Instead, there should be some form of init param that
> declares that the plugin is reconfigurable, maybe using something like
> "managed" - note that request handlers already provide a "handle" - the
> request handler name - and so don't need that to be separately specified:
> {code:xml}
>
>
>
> {code}
> and in the serialized schema - a handle needs to be specified here:
> {code:xml}
> positionIncrementGap="100">
> ...
>
>
>
> ...
> {code}
> All of the above examples use the existing plugin factory class names, but
> we'll have to create new RESTManager-aware classes to handle registration
> with RESTManager.
> Core/collection reloading should not be performed automatically when a REST
> API call is made to one of these RESTManager-mediated REST endpoints, since
> for batched config modifications, that could take way too long. But maybe
> reloading could be a query parameter to these REST API calls.
--
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-5655) Create a stopword filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
[ https://issues.apache.org/jira/browse/SOLR-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-5655: - Attachment: SOLR-5655.patch Depends on the patch posted for SOLR-5653. Deletes are implemented but not active from the REST API yet ... coming soon. > Create a stopword filter factory that is (re)configurable, and capable of > reporting its configuration, via REST API > --- > > Key: SOLR-5655 > URL: https://issues.apache.org/jira/browse/SOLR-5655 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Reporter: Steve Rowe > Attachments: SOLR-5655.patch > > > A stopword filter factory could be (re)configurable via REST API by > registering with the RESTManager described in SOLR-5653, and then responding > to REST API calls to modify its init params and its stopwords resource file. > Read-only (GET) REST API calls should also be provided, both for init params > and the stopwords resource file. > It should be possible to add/remove one or more entries in the stopwords > resource file. > We should probably use JSON for the REST request body, as is done in the > Schema REST API methods. -- 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-5653) Create a RESTManager to provide REST API endpoints for reconfigurable plugins
[
https://issues.apache.org/jira/browse/SOLR-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter updated SOLR-5653:
-
Attachment: SOLR-5653.patch
Here is the first attempt at a solution for the RestManager and implementations
for managing stop words and synonyms via a REST API.
A few things to notice about this implementation:
1) The RestManager needs to be able to read/write data from/to ZooKeeper if in
cloud mode or the local FS if in standalone mode. This is the purpose of the
ManagedResourceStorage.StorageIO interface. The idea here is that the
RestManager receives the StorageIO in its constructor from the SolrCore during
initialization. Currently, this is done in the SolrCore object, which has to do
an instanceof on the SolrResourceLoader to determine if it is ZK aware. This is
a bit hacky but I didn't see a better way to determine if a core is running in
ZK mode from within the SolrCore object. Currently, I provide 3 implementations
of StorageIO: ZooKeeperStorageIO, FileStorageIO, and InMemoryStorageIO.
2) A ManagedResource should be able to choose its own storage format, with the
storageIO being determined by the container.
This gives the ManagedResource developer flexibility in how they store data
without having to fuss with knowing how load/store bytes to ZK or local FS.
Currently, the only provided storage format is JSON, see:
ManagedResourceStorage.JsonStorage.
3) I'm using a "registry" object that is available from the SolrResourceLoader
to capture Solr components that declare themselves as being "managed". This is
needed because parsing the solrconfig.xml may encounter managed components
before it parses and initializes the RestManager. Basically, I wanted to
separate the registration of managed components from the initialization of the
RestManager and those components as I didn't want to force the position of the
element in the solrconfig.xml to be before all other components.
4) The design is based around the concept that there may be many different Solr
components that share a single ManagedResource. For instance, there may be many
ManagedStopFilterFactory instances declared in schema.xml that share a common
set of managed English stop words. Thus, I'm using the "observer" pattern which
allows Solr components to register as an observer of a shared ManagedResource.
This way we don't end up with 10 different managers of the same stop word list.
5) ManagedResourceObserver instances are notified once during core
initialization (load or reload) when the managed data is available. This is
their signal to internalize the managed data, such as the
ManagedStopFilterFactory converting the managed set of terms into a
CharArraySet used for creating StopFilters. This is a critical part of the
design in that updates to the managed data are not applied until a core is
reloaded. This is to avoid having analysis components with different views of
managed data, i.e. we don't want some of the replicas for a shard to have a
different set of stop words than the other shards.
6) I've provided one concrete ManagedResource implementation for managing a
word set, which is useful for stop words and protected words
(KeywordMarkerFilter). This implementation shows how to handle initArgs and a
managedList of words.
Known Issues:
a. The current RestManager attaches its registered endpoints using SolrRestApi,
which is configured to process requests to /collection/schema. While this path
works for stop words and synonyms, it doesn't work in the general case of any
type of ManagedResource. We need to figure out a better path for which to
configure the RestManager, but re-working that should be minor.
b. I had to make a few things public in the BaseSchemaResource class and
extended the RestManager.ManagedEndpoint class from it. We should refactor
BaseSchemaResource into a BaseSolrResource as it has usefulness beyond schema
related resources.
c. Deletes - the ManagedResource framework supports deletes but I wasn't sure
how to enable them in Restlet; again probably a minor issue in the restlet
config / setup.
> Create a RESTManager to provide REST API endpoints for reconfigurable plugins
> -
>
> Key: SOLR-5653
> URL: https://issues.apache.org/jira/browse/SOLR-5653
> Project: Solr
> Issue Type: Sub-task
>Reporter: Steve Rowe
> Attachments: SOLR-5653.patch
>
>
> It should be possible to reconfigure Solr plugins' resources and init params
> without directly editing the serialized schema or {{solrconfig.xml}} (see
> Hoss's arguments about this in the context of the schema, which also apply to
> {{solrconfig.xml}}, in the description of SOLR-4658)
> The RESTManager should allow plugins declared in either the schema or in
> {{solrconfig.xml}} t
[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-tabpanel&focusedCommentId=13897362#comment-13897362
]
ASF subversion and git services commented on SOLR-5709:
---
Commit 1566918 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1566918 ]
SOLR-5709: add missing license (merged trunk r1566914)
> 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
> Fix For: 5.0, 4.7
>
> 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 unsubs
[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_51) - Build # 3691 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/3691/ Java: 32bit/jdk1.7.0_51 -client -XX:+UseSerialGC All tests passed Build Log: [...truncated 29503 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:459: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:64: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build.xml:283: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1734: Rat problems were found! Total time: 101 minutes 15 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.7.0_51 -client -XX:+UseSerialGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - 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-tabpanel&focusedCommentId=13897359#comment-13897359
]
ASF subversion and git services commented on SOLR-5709:
---
Commit 1566914 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1566914 ]
SOLR-5709: add missing license
> 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
> Fix For: 5.0, 4.7
>
> 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
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.6.0_45) - Build # 9328 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9328/ Java: 32bit/jdk1.6.0_45 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 28714 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:459: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:64: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:283: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1734: Rat problems were found! Total time: 53 minutes 46 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.6.0_45 -client -XX:+UseParallelGC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - 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-tabpanel&focusedCommentId=13897324#comment-13897324 ] ASF subversion and git services commented on SOLR-3854: --- Commit 1566883 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1566883 ] SOLR-3854 : Reset ALLOW_SSL in afterClass. > 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-5649) Small ConnectionManager improvements
[ https://issues.apache.org/jira/browse/SOLR-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5649: -- Attachment: SOLR-5649.patch A patch addressing the above issues. > Small ConnectionManager improvements > > > Key: SOLR-5649 > URL: https://issues.apache.org/jira/browse/SOLR-5649 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6.1 >Reporter: Gregory Chanan >Assignee: Mark Miller >Priority: Minor > Fix For: 5.0, 4.7 > > Attachments: SOLR-5649.patch > > > I was just looking through the ConnectionManager and want to jot these down > before I forget them. I'm happy to make a patch if someone thinks it's > valuable as well. > - "clientConnected" doesn't seem to be read, can be eliminated > - "state" is a private volatile variable, but only used in one function -- > seems unlikely private volatile is what is wanted > - A comment explaining why disconnected() is not called in the case of > Expired would be helpful (Expired means we have already waited the timeout > period so we want to reject updates right away) -- 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] (SOLR-5649) Small ConnectionManager improvements
[ https://issues.apache.org/jira/browse/SOLR-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897313#comment-13897313 ] Mark Miller edited comment on SOLR-5649 at 2/11/14 12:06 AM: - A couple additional items: * We don't want to call connected() after updating the SolrZooKeeper instance in process - the new event thread will call on the connect event. We just want to start the reconnected thread and then that thread will process the thread death event and die. * Greg mentioned to me he also noticed the connected status variable was now in a non synchronized block - it should be synchronized or changed to a volatile. was (Author: markrmil...@gmail.com): A couple additional items: * We don't want to call connected() after updating the SolrZooKeeper instance in process - the new event thread will call on the connect event. We just want to start the reconnected thread and then that thread will process the thread death event and die. * Greg mentioned to me he also noticed the connected status variable was now in an synchronized block - it should be synchronized or changed to a volatile. > Small ConnectionManager improvements > > > Key: SOLR-5649 > URL: https://issues.apache.org/jira/browse/SOLR-5649 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6.1 >Reporter: Gregory Chanan >Assignee: Mark Miller >Priority: Minor > Fix For: 5.0, 4.7 > > > I was just looking through the ConnectionManager and want to jot these down > before I forget them. I'm happy to make a patch if someone thinks it's > valuable as well. > - "clientConnected" doesn't seem to be read, can be eliminated > - "state" is a private volatile variable, but only used in one function -- > seems unlikely private volatile is what is wanted > - A comment explaining why disconnected() is not called in the case of > Expired would be helpful (Expired means we have already waited the timeout > period so we want to reject updates right away) -- 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-5649) Small ConnectionManager improvements
[ https://issues.apache.org/jira/browse/SOLR-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897313#comment-13897313 ] Mark Miller commented on SOLR-5649: --- A couple additional items: * We don't want to call connected() after updating the SolrZooKeeper instance in process - the new event thread will call on the connect event. We just want to start the reconnected thread and then that thread will process the thread death event and die. * Greg mentioned to me he also noticed the connected status variable was now in an synchronized block - it should be synchronized or changed to a volatile. > Small ConnectionManager improvements > > > Key: SOLR-5649 > URL: https://issues.apache.org/jira/browse/SOLR-5649 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6.1 >Reporter: Gregory Chanan >Assignee: Mark Miller >Priority: Minor > Fix For: 5.0, 4.7 > > > I was just looking through the ConnectionManager and want to jot these down > before I forget them. I'm happy to make a patch if someone thinks it's > valuable as well. > - "clientConnected" doesn't seem to be read, can be eliminated > - "state" is a private volatile variable, but only used in one function -- > seems unlikely private volatile is what is wanted > - A comment explaining why disconnected() is not called in the case of > Expired would be helpful (Expired means we have already waited the timeout > period so we want to reject updates right away) -- 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-5649) Small ConnectionManager improvements
[
https://issues.apache.org/jira/browse/SOLR-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897312#comment-13897312
]
Mark Miller commented on SOLR-5649:
---
bq. "clientConnected" doesn't seem to be read, can be eliminated
Yup, a relica from original code.
bq. "state" is a private volatile variable, but only used in one function –
seems unlikely private volatile is what is wanted
Yeah, there used to be a getState method that we inherited but it is gone now.
bq. A comment explaining why disconnected() is not called in the case of
Expired would be helpful (Expired means we have already waited the timeout
period so we want to reject updates right away)
The current comment already says:
{quote} // we don't call disconnected because there
// is no need to start the timer - if we are expired
// likelyExpired can just be set to true{quote}
> Small ConnectionManager improvements
>
>
> Key: SOLR-5649
> URL: https://issues.apache.org/jira/browse/SOLR-5649
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.6.1
>Reporter: Gregory Chanan
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 5.0, 4.7
>
>
> I was just looking through the ConnectionManager and want to jot these down
> before I forget them. I'm happy to make a patch if someone thinks it's
> valuable as well.
> - "clientConnected" doesn't seem to be read, can be eliminated
> - "state" is a private volatile variable, but only used in one function --
> seems unlikely private volatile is what is wanted
> - A comment explaining why disconnected() is not called in the case of
> Expired would be helpful (Expired means we have already waited the timeout
> period so we want to reject updates right away)
--
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-5649) Small ConnectionManager improvements
[ https://issues.apache.org/jira/browse/SOLR-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5649: -- Priority: Minor (was: Trivial) Affects Version/s: (was: 4.7) 4.6.1 Fix Version/s: 5.0 Assignee: Mark Miller Issue Type: Bug (was: Improvement) > Small ConnectionManager improvements > > > Key: SOLR-5649 > URL: https://issues.apache.org/jira/browse/SOLR-5649 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.6.1 >Reporter: Gregory Chanan >Assignee: Mark Miller >Priority: Minor > Fix For: 5.0, 4.7 > > > I was just looking through the ConnectionManager and want to jot these down > before I forget them. I'm happy to make a patch if someone thinks it's > valuable as well. > - "clientConnected" doesn't seem to be read, can be eliminated > - "state" is a private volatile variable, but only used in one function -- > seems unlikely private volatile is what is wanted > - A comment explaining why disconnected() is not called in the case of > Expired would be helpful (Expired means we have already waited the timeout > period so we want to reject updates right away) -- 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-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5477: --- Attachment: SOLR-5477-updated.patch Updated patch. There were quite a few conflicts and I think I fixed them. It'd be good if whoever commits this has a final look at it. > Async execution of OverseerCollectionProcessor tasks > > > Key: SOLR-5477 > URL: https://issues.apache.org/jira/browse/SOLR-5477 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Noble Paul >Assignee: Anshum Gupta > Attachments: SOLR-5477-CoreAdminStatus.patch, > SOLR-5477-updated.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, > SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, > SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, > SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, > SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch > > > Typical collection admin commands are long running and it is very common to > have the requests get timed out. It is more of a problem if the cluster is > very large.Add an option to run these commands asynchronously > add an extra param async=true for all collection commands > the task is written to ZK and the caller is returned a task id. > as separate collection admin command will be added to poll the status of the > task > command=status&id=7657668909 > if id is not passed all running async tasks should be listed > A separate queue is created to store in-process tasks . After the tasks are > completed the queue entry is removed. OverSeerColectionProcessor will perform > these tasks in multiple threads -- 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-5561) DefaultSimilarity 'init' method is not called, if the similarity plugin is not explicitly declared in the schema
[ https://issues.apache.org/jira/browse/SOLR-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-5561. Resolution: Fixed Thanks everyone! > DefaultSimilarity 'init' method is not called, if the similarity plugin is > not explicitly declared in the schema > > > Key: SOLR-5561 > URL: https://issues.apache.org/jira/browse/SOLR-5561 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 4.6 >Reporter: Isaac Hebsh >Assignee: Hoss Man > Labels: similarity > Fix For: 5.0, 4.7 > > Attachments: SOLR-5561.patch, SOLR-5561.patch, SOLR-5561.patch, > SOLR-5561.patch > > > As a result, discountOverlap is not initialized to true, and the default > behavior is that multiple terms on the same position DO affect the fieldNorm. > this is not the intended default. -- 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-tabpanel&focusedCommentId=13897305#comment-13897305 ] Steve Davids commented on SOLR-3854: Looks like the ALLOW_SSL property doesn't get reset to true in the afterClass method (should replace sslConfig = null; in SolrTestCaseJ4). Other than that, I don't see any glaring issues - have a timeline for pushing this to the 4.x branch? If there are any outstanding issues you would like me to look at just let me know. > 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-5561) DefaultSimilarity 'init' method is not called, if the similarity plugin is not explicitly declared in the schema
[ https://issues.apache.org/jira/browse/SOLR-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897302#comment-13897302 ] ASF subversion and git services commented on SOLR-5561: --- Commit 1566871 from hoss...@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1566871 ] SOLR-5561: Fix implicit DefaultSimilarityFactory initialization in IndexSchema to properly specify discountOverlap option (merge r1566842) > DefaultSimilarity 'init' method is not called, if the similarity plugin is > not explicitly declared in the schema > > > Key: SOLR-5561 > URL: https://issues.apache.org/jira/browse/SOLR-5561 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 4.6 >Reporter: Isaac Hebsh >Assignee: Hoss Man > Labels: similarity > Fix For: 5.0, 4.7 > > Attachments: SOLR-5561.patch, SOLR-5561.patch, SOLR-5561.patch, > SOLR-5561.patch > > > As a result, discountOverlap is not initialized to true, and the default > behavior is that multiple terms on the same position DO affect the fieldNorm. > this is not the intended default. -- 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-5561) DefaultSimilarity 'init' method is not called, if the similarity plugin is not explicitly declared in the schema
[ https://issues.apache.org/jira/browse/SOLR-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897275#comment-13897275 ] ASF subversion and git services commented on SOLR-5561: --- Commit 1566842 from hoss...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1566842 ] SOLR-5561: Fix implicit DefaultSimilarityFactory initialization in IndexSchema to properly specify discountOverlap option > DefaultSimilarity 'init' method is not called, if the similarity plugin is > not explicitly declared in the schema > > > Key: SOLR-5561 > URL: https://issues.apache.org/jira/browse/SOLR-5561 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 4.6 >Reporter: Isaac Hebsh >Assignee: Hoss Man > Labels: similarity > Fix For: 5.0, 4.7 > > Attachments: SOLR-5561.patch, SOLR-5561.patch, SOLR-5561.patch, > SOLR-5561.patch > > > As a result, discountOverlap is not initialized to true, and the default > behavior is that multiple terms on the same position DO affect the fieldNorm. > this is not the intended default. -- 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-5536) Add ValueSource collapse criteria to CollapsingQParsingPlugin
[
https://issues.apache.org/jira/browse/SOLR-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897277#comment-13897277
]
ASF subversion and git services commented on SOLR-5536:
---
Commit 1566844 from [~joel.bernstein] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1566844 ]
SOLR-5536: Added a proper ValueSource context
> Add ValueSource collapse criteria to CollapsingQParsingPlugin
> -
>
> Key: SOLR-5536
> URL: https://issues.apache.org/jira/browse/SOLR-5536
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 4.6
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.0, 4.7
>
> Attachments: SOLR-5536.patch, SOLR-5536.patch, SOLR-5536.patch,
> SOLR-5536.patch
>
>
> It would be useful for the CollapsingQParserPlugin to support ValueSource
> collapse criteria.
> Proposed syntax:
> {code}
> fq={!collapse field=collapse_field max=value_source}
> {code}
> This ticket will also introduce a function query called "cscore", which will
> return the score of the current document being collapsed. This will allow
> score to be incorporated into collapse criteria functions.
> A simple example of the cscore usage:
> {code}
> fq={!collapse field=collapse_field max=sum(cscore(), field(x))}
> {code}
>
--
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-5400) Long text matching email local-part rule in UAX29URLEmailTokenizer causes extremely slow tokenization
[ https://issues.apache.org/jira/browse/LUCENE-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897182#comment-13897182 ] Edu Garcia commented on LUCENE-5400: Hi. We've hit this bug in Atlassian Confluence (https://jira.atlassian.com/browse/CONF-32566) and it's causing a bit of customer pain. Is [~steve_rowe]'s solution a viable one, or is someone working on a better one? Thank you! > Long text matching email local-part rule in UAX29URLEmailTokenizer causes > extremely slow tokenization > - > > Key: LUCENE-5400 > URL: https://issues.apache.org/jira/browse/LUCENE-5400 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Chris Geeringh >Assignee: Steve Rowe > > This is a pretty nasty bug, and causes the cluster to stop accepting updates. > I'm not sure how to consistently reproduce it but I have done so numerous > times. Switching to a whitespace tokenizer improved indexing speed, and I > never got the issue again. > I'm running a 4.6 Snapshot - I had issues with deadlocks with numerous > versions of Solr, and have finally narrowed down the problem to this code, > which affects many/all(?) versions of Solr. > When the thread hits this issue it uses 100% CPU, restarting the node which > has the error allows indexing to continue until hit again. Here is thread > dump: > http-bio-8080-exec-45 (201) > > org.apache.lucene.analysis.standard.UAX29URLEmailTokenizerImpl.getNextToken(UAX29URLEmailTokenizerImpl.java:4343) > > org.apache.lucene.analysis.standard.UAX29URLEmailTokenizer.incrementToken(UAX29URLEmailTokenizer.java:147) > > org.apache.lucene.analysis.util.FilteringTokenFilter.incrementToken(FilteringTokenFilter.java:82) > > org.apache.lucene.analysis.core.LowerCaseFilter.incrementToken(LowerCaseFilter.java:54) > > org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:174) > > org.apache.lucene.index.DocFieldProcessor.processDocument(DocFieldProcessor.java:248) > > org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:253) > > org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:453) > org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1517) > > org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:217) > > org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69) > > org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51) > > org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:583) > > org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:719) > > org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:449) > > org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:89) > > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:151) > > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:131) > org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:221) > > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:116) > org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:186) > org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:112) > > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:158) > > org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:99) > org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:58) > > org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92) > > org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74) > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > org.apache.solr.core.SolrCore.execute(SolrCore.java:1859) > > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703) > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406) > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195) > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > > org.apache.catalina.core.Appli
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_51) - Build # 3766 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3766/ Java: 32bit/jdk1.7.0_51 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([E370FFF9EA15F741:CCD95BE83D9AB845]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused(BasicHttpSolrServerTest.java:159) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) 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 11584 lines...] [junit4] Suite: org.apache.solr.client.solrj.impl.BasicHttpSolrServe
[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-tabpanel&focusedCommentId=13897118#comment-13897118 ] Yonik Seeley commented on LUCENE-5440: -- OpenBitSet is part of the Solr APIs in a number of places, so if we make these changes, I guess it should be trunk only? > 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-solr.patch, 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] [Updated] (SOLR-5561) DefaultSimilarity 'init' method is not called, if the similarity plugin is not explicitly declared in the schema
[ https://issues.apache.org/jira/browse/SOLR-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-5561: --- Attachment: SOLR-5561.patch Ahmet & Vitaliy - thanks for your tests & improvements! Here's a slightly updated patch... * introduce a String constant for the "discountOverlaps" param name (since it's now used outside the class in IndexSchema, a constant is appropriate) * consolidated the two tests classes into one to reduce some duplication & leverage some existing BaseSimilarityTestCase helper methods * change the tests to leverage the Version enum values instead of just version string constants (this will make it easier to find/remove tests refering to 4.6 and 4.7 once those constants are no longer explicitly supported) * added some javadocs I'll commit soon unless anyone sees any problems? > DefaultSimilarity 'init' method is not called, if the similarity plugin is > not explicitly declared in the schema > > > Key: SOLR-5561 > URL: https://issues.apache.org/jira/browse/SOLR-5561 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 4.6 >Reporter: Isaac Hebsh >Assignee: Hoss Man > Labels: similarity > Fix For: 5.0, 4.7 > > Attachments: SOLR-5561.patch, SOLR-5561.patch, SOLR-5561.patch, > SOLR-5561.patch > > > As a result, discountOverlap is not initialized to true, and the default > behavior is that multiple terms on the same position DO affect the fieldNorm. > this is not the intended default. -- 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-solr.patch Patch moves solr/ code to use FixedBitSet instead of OpenBitSet. I ran into few issues e.g. w/ bulk operations such as or/union, where OpenBitSet grew the underlying long[]. Now it needs to grow on the outside. I think I'll add a check to FBS.or() to make sure the given bitset is not bigger than the current one. Anyway, I still didn't run tests, just wanted to checkpoint. There are no more uses of OBS in solr/. > 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-solr.patch, 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] [Commented] (LUCENE-5437) ASCIIFoldingFilter that emits both unfolded and folded tokens
[ https://issues.apache.org/jira/browse/LUCENE-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897083#comment-13897083 ] Simon Willnauer commented on LUCENE-5437: - I like this patch much better. I wonder if we can come up with a better naming for the variables / options. In _PatternCaptureGroupTokenFilter_ we use _preserveOriginal_ which I kind of like better. For the tests I wonder if you can make _assertNextTerms_ accept a _ASCIIFoldingFilter_ instead of a _TokenFilter_ and add a getter to it so we can randomly set if the orig should be preserved? That would also prevent the subclass? > ASCIIFoldingFilter that emits both unfolded and folded tokens > - > > Key: LUCENE-5437 > URL: https://issues.apache.org/jira/browse/LUCENE-5437 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Nik Everett >Assignee: Simon Willnauer >Priority: Minor > Attachments: LUCENE-5437.patch > > > I've found myself wanting an ASCIIFoldingFilter that emits both the folded > tokens and the original, unfolded tokens. -- 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-5437) ASCIIFoldingFilter that emits both unfolded and folded tokens
[ https://issues.apache.org/jira/browse/LUCENE-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nik Everett updated LUCENE-5437: Attachment: (was: LUCENE-5437.patch) > ASCIIFoldingFilter that emits both unfolded and folded tokens > - > > Key: LUCENE-5437 > URL: https://issues.apache.org/jira/browse/LUCENE-5437 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Nik Everett >Assignee: Simon Willnauer >Priority: Minor > Attachments: LUCENE-5437.patch > > > I've found myself wanting an ASCIIFoldingFilter that emits both the folded > tokens and the original, unfolded tokens. -- 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-5536) Add ValueSource collapse criteria to CollapsingQParsingPlugin
[
https://issues.apache.org/jira/browse/SOLR-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897047#comment-13897047
]
ASF subversion and git services commented on SOLR-5536:
---
Commit 1566754 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1566754 ]
SOLR-5536: Added a proper ValueSource context
> Add ValueSource collapse criteria to CollapsingQParsingPlugin
> -
>
> Key: SOLR-5536
> URL: https://issues.apache.org/jira/browse/SOLR-5536
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 4.6
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.0, 4.7
>
> Attachments: SOLR-5536.patch, SOLR-5536.patch, SOLR-5536.patch,
> SOLR-5536.patch
>
>
> It would be useful for the CollapsingQParserPlugin to support ValueSource
> collapse criteria.
> Proposed syntax:
> {code}
> fq={!collapse field=collapse_field max=value_source}
> {code}
> This ticket will also introduce a function query called "cscore", which will
> return the score of the current document being collapsed. This will allow
> score to be incorporated into collapse criteria functions.
> A simple example of the cscore usage:
> {code}
> fq={!collapse field=collapse_field max=sum(cscore(), field(x))}
> {code}
>
--
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] (SOLR-5652) Heisenbug in DistribCursorPagingTest: "walk already seen ..."
[
https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897043#comment-13897043
]
Steve Rowe edited comment on SOLR-5652 at 2/10/14 9:31 PM:
---
{quote}
bq. Resolving, as I think we have now addressed all of the
missing-docvalues-related failures we've seen.
I actually want to keep this one open a bit ... give it another week or two,
and assuming no more failures i want to dial back on some of the extra logging
we added here to be less verbose in the non-failure case.
{quote}
Sure, makes sense.
was (Author: steve_rowe):
{quote}
bq. Resolving, as I think we have now addressed all of the
missing-docvalues-related failures we've seen.
I actually want to keep this one open a bit ... give it another week or two,
and assuming no more failures i want to dial back on some of the extra logging
we added here to be less verbose in the non-failure case.
{quote}
Sure, make sense.
> 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
> Fix For: 4.7
>
> 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-5652) Heisenbug in DistribCursorPagingTest: "walk already seen ..."
[
https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897043#comment-13897043
]
Steve Rowe commented on SOLR-5652:
--
{quote}
bq. Resolving, as I think we have now addressed all of the
missing-docvalues-related failures we've seen.
I actually want to keep this one open a bit ... give it another week or two,
and assuming no more failures i want to dial back on some of the extra logging
we added here to be less verbose in the non-failure case.
{quote}
Sure, make sense.
> 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
> Fix For: 4.7
>
> 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] [Reopened] (SOLR-5652) Heisenbug in DistribCursorPagingTest: "walk already seen ..."
[ https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reopened SOLR-5652: bq. I committed my patch to also skip sorting on *_dv fields when the codec doesn't support missing docvalues, to trunk and branch_4x. thanks steve. bq. Resolving, as I think we have now addressed all of the missing-docvalues-related failures we've seen. I actually want to keep this one open a bit ... give it another week or two, and assuming no more failures i want to dial back on some of the extra logging we added here to be less verbose in the non-failure case. > 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 > Fix For: 4.7 > > 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] [Resolved] (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:all-tabpanel
]
Steve Rowe resolved SOLR-5709.
--
Resolution: Fixed
Fix Version/s: 4.7
5.0
Committed to branch_4x and trunk.
> 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
> Fix For: 5.0, 4.7
>
> 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-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-tabpanel&focusedCommentId=13897014#comment-13897014
]
ASF subversion and git services commented on SOLR-5709:
---
Commit 1566746 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1566746 ]
SOLR-5709: Highlighting grouped duplicate docs from different shards with
group.limit > 1 throws ArrayIndexOutOfBoundsException (merged trunk r1566743)
> 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
> Fix For: 5.0, 4.7
>
> 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 J
[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-tabpanel&focusedCommentId=13897007#comment-13897007
]
ASF subversion and git services commented on SOLR-5709:
---
Commit 1566743 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1566743 ]
SOLR-5709: Highlighting grouped duplicate docs from different shards with
group.limit > 1 throws ArrayIndexOutOfBoundsException
> 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)
[jira] [Resolved] (SOLR-5652) Heisenbug in DistribCursorPagingTest: "walk already seen ..."
[
https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-5652.
--
Resolution: Fixed
Fix Version/s: 4.7
I committed my patch to also skip sorting on {{\*_dv}} fields when the codec
doesn't support missing docvalues, to trunk and branch_4x.
Resolving, as I think we have now addressed all of the
missing-docvalues-related failures we've seen.
> 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
> Fix For: 4.7
>
> 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-5652) Heisenbug in DistribCursorPagingTest: "walk already seen ..."
[ https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896996#comment-13896996 ] ASF subversion and git services commented on SOLR-5652: --- Commit 1566742 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1566742 ] SOLR-5652: in cursor tests, don't sort on 'plain' docvalue fields (i.e., those using standard Lucene sorting for missing values) when the codec doesn't support missing docvalues. (merged trunk r1566741) > 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-5652) Heisenbug in DistribCursorPagingTest: "walk already seen ..."
[ https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896992#comment-13896992 ] ASF subversion and git services commented on SOLR-5652: --- Commit 1566741 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1566741 ] SOLR-5652: in cursor tests, don't sort on 'plain' docvalue fields (i.e., those using standard Lucene sorting for missing values) when the codec doesn't support missing docvalues. > 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] (LUCENE-5441) Decouple DocIdSet from OpenBitSet and FixedBitSet
[
https://issues.apache.org/jira/browse/LUCENE-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896944#comment-13896944
]
Shai Erera commented on LUCENE-5441:
Uwe, just a wild thought -- since you already break back-compat by making FBS
not extend DocIdSet, can we also rename it to IntBitSet? Migrating your code
following those two changes is equally trivial... if not, then how about we
keep FBS as-is, deprecated, and do all this work on a new IntBitSet? I prefer
the first approach since it means less work (and also I think that writing a
Filter is quite expert).
> 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, 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-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 after LUCENE-5440 was committed. This includes the following extra
features:
- FixedBitDocIdSet was added instead of the asDocIdSet() method.
- removed the OpenBitSetDISI optimizations.
- The and/or/andNot/xor(DISI) methods are no longer available in FixedBitSet.
Those are only available in FixedBitDocIdSet. This leads t some additional
wrapping or less wrapping depending where it was used before. I did not review
all the automatic changes I did, surely there could be some private method
signatures changed in ChainedFilter/BooleanFilter to reduce wrapping.
- I also optimized FixedBitDocIdSet.xor(DISI) to use bitwise XOR, if the
iterator is a FixedBitSet one. This was missing in Shai's patch.
The current code does not change the DocIdSet abstract interface to support
inplace and/or/... (especially as this is only supported by bitsets, but not
the other DIS impls?!). I am also not yet happy with the current state of this
DIS wrapping. In any case - FixedBitSet is now clean from any DocIdSet uses!
It's just a BitSet, nothing more - like the Long one.
> 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, 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] [Assigned] (SOLR-5561) DefaultSimilarity 'init' method is not called, if the similarity plugin is not explicitly declared in the schema
[ https://issues.apache.org/jira/browse/SOLR-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reassigned SOLR-5561: -- Assignee: Hoss Man > DefaultSimilarity 'init' method is not called, if the similarity plugin is > not explicitly declared in the schema > > > Key: SOLR-5561 > URL: https://issues.apache.org/jira/browse/SOLR-5561 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 4.6 >Reporter: Isaac Hebsh >Assignee: Hoss Man > Labels: similarity > Fix For: 5.0, 4.7 > > Attachments: SOLR-5561.patch, SOLR-5561.patch, SOLR-5561.patch > > > As a result, discountOverlap is not initialized to true, and the default > behavior is that multiple terms on the same position DO affect the fieldNorm. > this is not the intended default. -- 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-MAVEN] Lucene-Solr-Maven-trunk #1101: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1101/ All tests passed Build Log: [...truncated 48822 lines...] [mvn] [INFO] - [mvn] [INFO] - [mvn] [ERROR] COMPILATION ERROR : [mvn] [INFO] - [...truncated 373 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:476: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:176: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/extra-targets.xml:77: Java returned: 1 Total time: 46 minutes 12 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5671) Heisenbug #2 in DistribCursorPagingTest: full walk returns one fewer doc than expected
[ https://issues.apache.org/jira/browse/SOLR-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-5671. Resolution: Fixed Fix Version/s: 4.7 5.0 > Heisenbug #2 in DistribCursorPagingTest: full walk returns one fewer doc than > expected > --- > > Key: SOLR-5671 > URL: https://issues.apache.org/jira/browse/SOLR-5671 > Project: Solr > Issue Type: Bug >Affects Versions: 4.7 >Reporter: Steve Rowe > Fix For: 5.0, 4.7 > > > Twice on Uwe's Jenkins, DistribCursorPagingTest has paged through a small > number of indexed docs and retrieved one fewer doc than the number of indexed > docs. Both of these failures were on trunk on Windows: > http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3708/ > http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3713/ > I've also seen this twice on trunk on my OS X laptop (out of 875 trials). > None of the seeds have reproduced for me. > All the failures were using either Lucene41 or Lucene42 codec -- 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-5671) Heisenbug #2 in DistribCursorPagingTest: full walk returns one fewer doc than expected
[ https://issues.apache.org/jira/browse/SOLR-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896840#comment-13896840 ] Hoss Man commented on SOLR-5671: Given this... bq. All the failures were using either Lucene41 or Lucene42 codec ... and the fact that (as far as i can tell) we haven't seen any more failures of this type since the codec constraints were added to the test in SOLR-5652, my hunch is that this is the same test bug manifesting itself in a slightly different way: just as the non-deterministic behavior the docvalues w/missing value caused a doc to appear twice in SOLR-5652, shifting from it's originla position to a later position on a subsequent request, it's easily concievable that the same non-deterministic behavior could cause a doc to shift to an early position -- prior to the current cursor page -- on subsequent requests, causing that doc to be skipped entirely. I think we can go ahead and resolve this -- if it does pop up again we can re-open (and we'll have the better assertion failure message steve added to help diagnose) > Heisenbug #2 in DistribCursorPagingTest: full walk returns one fewer doc than > expected > --- > > Key: SOLR-5671 > URL: https://issues.apache.org/jira/browse/SOLR-5671 > Project: Solr > Issue Type: Bug >Affects Versions: 4.7 >Reporter: Steve Rowe > Fix For: 5.0, 4.7 > > > Twice on Uwe's Jenkins, DistribCursorPagingTest has paged through a small > number of indexed docs and retrieved one fewer doc than the number of indexed > docs. Both of these failures were on trunk on Windows: > http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3708/ > http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3713/ > I've also seen this twice on trunk on my OS X laptop (out of 875 trials). > None of the seeds have reproduced for me. > All the failures were using either Lucene41 or Lucene42 codec -- 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-5438) add near-real-time replication
[ https://issues.apache.org/jira/browse/LUCENE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5438: --- Attachment: LUCENE-5438.patch New patch, improving the test case. I added some abstraction (Replica class), and the test now randomly commits/stops/starts replicas. > add near-real-time replication > -- > > Key: LUCENE-5438 > URL: https://issues.apache.org/jira/browse/LUCENE-5438 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/replicator >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, 4.7 > > Attachments: LUCENE-5438.patch, LUCENE-5438.patch > > > Lucene's replication module makes it easy to incrementally sync index > changes from a master index to any number of replicas, and it > handles/abstracts all the underlying complexity of holding a > time-expiring snapshot, finding which files need copying, syncing more > than one index (e.g., taxo + index), etc. > But today you must first commit on the master, and then again the > replica's copied files are fsync'd, because the code operates on > commit points. But this isn't "technically" necessary, and it mixes > up durability and fast turnaround time. > Long ago we added near-real-time readers to Lucene, for the same > reason: you shouldn't have to commit just to see the new index > changes. > I think we should do the same for replication: allow the new segments > to be copied out to replica(s), and new NRT readers to be opened, to > fully decouple committing from visibility. This way apps can then > separately choose when to replicate (for freshness), and when to > commit (for durability). > I think for some apps this could be a compelling alternative to the > "re-index all documents on each shard" approach that Solr Cloud / > ElasticSearch implement today, and it may also mean that the > transaction log can remain external to / above the cluster. -- 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-4.x-Linux (64bit/jdk1.7.0_51) - Build # 9325 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9325/ Java: 64bit/jdk1.7.0_51 -XX:-UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 7350 lines...] [junit4] JVM J1: stdout was not empty, see: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/test/temp/junit4-J1-20140210_171831_397.sysout [junit4] >>> JVM J1: stdout (verbatim) [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0x7fed8569efab, pid=15145, tid=140657468221184 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13) [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 ) [junit4] # Problematic frame: [junit4] # J org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.readPositions(IILorg/apache/lucene/util/packed/PackedInts$Reader;Lorg/apache/lucene/util/packed/PackedInts$Reader;[III[[I)[[I [junit4] # [junit4] # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4] # [junit4] # An error report file with more information is saved as: [junit4] # /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/test/J1/hs_err_pid15145.log [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # http://bugreport.sun.com/bugreport/crash.jsp [junit4] # [junit4] <<< JVM J1: EOF [...truncated 20 lines...] [junit4] ERROR: JVM J1 ended with an exception, command line: /var/lib/jenkins/tools/java/64bit/jdk1.7.0_51/jre/bin/java -XX:-UseCompressedOops -XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/heapdumps -Dtests.prefix=tests -Dtests.seed=F5E506995138D958 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.7 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/test/temp -Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/tests.policy -Dlucene.version=4.7-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.disableHdfs=true -Dfile.encoding=UTF-8 -classpath /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/classes/test:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/junit-4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.13.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jsch.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-net.jar:/var/lib/jenkins/tools/hudso
[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-tabpanel&focusedCommentId=13896715#comment-13896715
]
Erick Erickson commented on SOLR-5704:
--
Thanks guys!
> 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
> Fix For: 5.0, 4.7
>
> Attachments: SOLR-5704.patch, 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-tabpanel&focusedCommentId=13896716#comment-13896716 ] ASF subversion and git services commented on LUCENE-5440: - Commit 1566670 from [~shaie] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1566670 ] LUCENE-5440: Add LongBitSet to handle large number of bits; replace usage of OpenBitSet by FixedBitSet/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] [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-tabpanel&focusedCommentId=13896717#comment-13896717 ] Shai Erera commented on LUCENE-5440: Committed this patch to trunk and 4x. I will work on the solr/ code ... at least, I'll make a best effort :). > 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] [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-tabpanel&focusedCommentId=13896700#comment-13896700 ] ASF subversion and git services commented on LUCENE-5440: - Commit 152 from [~shaie] in branch 'dev/trunk' [ https://svn.apache.org/r152 ] LUCENE-5440: Add LongBitSet to handle large number of bits; replace usage of OpenBitSet by FixedBitSet/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] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896513#comment-13896513
]
ASF subversion and git services commented on SOLR-5476:
---
Commit 1566624 from [~noble.paul] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1566624 ]
SOLR-5476 added testcase
> 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, 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=addrole&role=overseer&node=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-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896496#comment-13896496
]
ASF subversion and git services commented on SOLR-5476:
---
Commit 1566620 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1566620 ]
SOLR-5476 added testcase
> 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, 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=addrole&role=overseer&node=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-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-5476:
-
Attachment: SOLR-5476.patch
Another testcase to kill an existing overseer and checking for another one to
takeover
> 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, 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=addrole&role=overseer&node=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] [Created] (SOLR-5712) Nullpointer while using TermVectorComponent when all the defined 'termVectors' fields of a document are empty.
Ron van der Vegt created SOLR-5712: -- Summary: Nullpointer while using TermVectorComponent when all the defined 'termVectors' fields of a document are empty. Key: SOLR-5712 URL: https://issues.apache.org/jira/browse/SOLR-5712 Project: Solr Issue Type: Bug Affects Versions: 4.6 Reporter: Ron van der Vegt I defined three fields in my schema: I indexed around 3000 documents. In one of the documents all the three fields above are empty. On index time there is no issue. But when I tried to access my vector component request handler I get an nullpointer exception. I removed the document, where all the three fields are empy, indexed again and the exception is gone. My request handler: true tvComponent http://localhost:8983/solr/tvrh?q=*:* 257414 [qtp1106570297-16] ERROR org.apache.solr.servlet.SolrDispatchFilter – null:java.lang.NullPointerException at org.apache.solr.handler.component.TermVectorComponent.process(TermVectorComponent.java:322) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:710) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:197) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) at 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.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) 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.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) 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.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) 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:744) -- 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-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 resolved SOLR-5704.
-
Resolution: Fixed
Fix Version/s: 4.7
5.0
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
> Fix For: 5.0, 4.7
>
> Attachments: SOLR-5704.patch, 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-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-tabpanel&focusedCommentId=13896450#comment-13896450
]
ASF subversion and git services commented on SOLR-5704:
---
Commit 1566600 from [~romseygeek] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1566600 ]
SOLR-5704: new cores should be created under coreRootDirectory
> 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, 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-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-tabpanel&focusedCommentId=13896448#comment-13896448
]
ASF subversion and git services commented on SOLR-5704:
---
Commit 1566598 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1566598 ]
SOLR-5704: new cores should be created under coreRootDirectory
> 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, 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] [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
Updated patch, fixing a couple of test fails due to TestHarness creating a
ConfigSolr object with a null resource loader.
> 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, 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-5609) Don't let cores create slices/named replicas
[
https://issues.apache.org/jira/browse/SOLR-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896397#comment-13896397
]
Noble Paul commented on SOLR-5609:
--
Takeaway from my discussion with [~markrmil...@gmail.com] .
If legacyCloud=false , delete the "collection1" or "defaultcol" cores when
they send the STATE commands
> Don't let cores create slices/named replicas
>
>
> Key: SOLR-5609
> URL: https://issues.apache.org/jira/browse/SOLR-5609
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 5.0, 4.7
>
>
> In SolrCloud, it is possible for a core to come up in any node , and register
> itself with an arbitrary slice/coreNodeName. This is a legacy requirement and
> we would like to make it only possible for Overseer to initiate creation of
> slice/replicas
> We plan to introduce cluster level properties at the top level
> /cluster-props.json
> {code:javascript}
> {
> "noSliceOrReplicaByCores":true"
> }
> {code}
> If this property is set to true, cores won't be able to send STATE commands
> with unknown slice/coreNodeName . Those commands will fail at Overseer. This
> is useful for SOLR-5310 / SOLR-5311 where a core/replica is deleted by a
> command and it comes up later and tries to create a replica/slice
--
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-tabpanel&focusedCommentId=13896393#comment-13896393
]
Shai Erera commented on LUCENE-5441:
OK, but I prefer a shorter name. I see that we have DocIdBitSet, which works on
top of Java's BitSet. But looks like it's used only in tests today, so maybe we
hijack it to use FixedBitSet? Why do we need to offer something on top of
Java's when we have our own?
> 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-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896379#comment-13896379 ] Shai Erera commented on LUCENE-5440: I removed the internal annotation from LongBitSet and also FixedBitSet. I agree FBS is not internal... > 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] [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-tabpanel&focusedCommentId=13896366#comment-13896366
]
Adrien Grand commented on LUCENE-5441:
--
+1 on decoupling DocIdSet from our bit sets. The current patch looks good to me
but I would also be happy with a dedicated class instead of the anonymous
wrapper.
bq. I would call it maybe BitsDocIdSet
We have a {{Bits}} interface that provides random access to boolean values.
Since this class would only work with FixedBitSet, I think Uwe's proposition
would be more appropriate?
> 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-5440) Add LongFixedBitSet and replace usage of OpenBitSet
[ https://issues.apache.org/jira/browse/LUCENE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896358#comment-13896358 ] Uwe Schindler commented on LUCENE-5440: --- +1 to commit, the @lucene.internal problems can be solved separately! > 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-Windows (64bit/jdk1.7.0_60-ea-b04) - Build # 3764 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3764/ Java: 64bit/jdk1.7.0_60-ea-b04 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([D19514919F7771AE:FE3CB08048F83EAA]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused(BasicHttpSolrServerTest.java:159) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) 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 11345 lines...] [junit4] Suite: org.apache.solr.client.
[jira] [Commented] (LUCENE-3459) Change ChainedFilter to use FixedBitSet
[ https://issues.apache.org/jira/browse/LUCENE-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896308#comment-13896308 ] Uwe Schindler commented on LUCENE-3459: --- Cool, thanks! I wanted to do this since 4.0 :( Many thanks! > 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
