[jira] [Commented] (SOLR-3901) Highlighting: InvalidTokenOffsetsException: ReversedWildcardFilter
[ https://issues.apache.org/jira/browse/SOLR-3901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653578#comment-13653578 ] Holger Floerke commented on SOLR-3901: -- @Ken: In fact the problem still persists in version 4.x Is anybody able to have a look at this bug if I post testdata? Highlighting: InvalidTokenOffsetsException: ReversedWildcardFilter -- Key: SOLR-3901 URL: https://issues.apache.org/jira/browse/SOLR-3901 Project: Solr Issue Type: Bug Affects Versions: 3.6 Reporter: jerico Using Highlighting together with the ReversedWildcardFilter does not work in our case. We (sometimes) get InvalidTokenOffsetExceptions. Removing the ReversedWildcardFilterFactory from all analysis chains solves the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4741) Deleting a collection should set DELETE_DATA_DIR to true.
[ https://issues.apache.org/jira/browse/SOLR-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653579#comment-13653579 ] Shalin Shekhar Mangar commented on SOLR-4741: - [~markrmiller] -- Should this be back ported to 4.3.1? Deleting a collection should set DELETE_DATA_DIR to true. - Key: SOLR-4741 URL: https://issues.apache.org/jira/browse/SOLR-4741 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 5.0, 4.4 Currently we remove the instance dir, which usually contains the data dir, but it won't always. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Sorry for JIRA mails
I found out that Lucene/Solr 4.3 was not marked as released version in JIRA. I e-mailed about it 2 days ago but wasn't sure what to do with it. http://goo.gl/xXhgF D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653587#comment-13653587
]
Commit Tag Bot commented on SOLR-4760:
--
[lucene_solr_4_3 commit] elyograg
http://svn.apache.org/viewvc?view=revisionrevision=1480893
SOLR-4760: Include core name in logs when loading schema. (merge trunk r1480882)
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make tests.failfast default to true
I thought to make the change in LuceneTestCase.
Shai
On Fri, May 10, 2013 at 8:56 AM, Dawid Weiss
dawid.we...@cs.put.poznan.plwrote:
I don't care much. If you do though, you can specify your own override
in any of these locations?
property file=${user.home}/lucene.build.properties/
property file=${user.home}/build.properties/
property file=${basedir}/build.properties/
property file=${common.dir}/build.properties/
Or is this something you'd like to promote to the top level?
Dawid
On Fri, May 10, 2013 at 7:20 AM, Shai Erera ser...@gmail.com wrote:
Hi
Can we default tests.failfast to true? I don't know how common it is to
run
with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to see
all
N tests finish.
At any rate, if someone wishes to, he can always specify
-Dtests.failfast=false. It now depends what is the default behavior we
want
to have.
Any thoughts?
Shai
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey resolved SOLR-4760.
Resolution: Fixed
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Compressed field reader and memory problems with atomic updates
Erick, I would try to limit the number of threads to aleviate the problem, honestly, gong much above #CPU cores rarely makes things better. Just let excessive update commands wait in some queue. We impose hard limits intercepting update chain and configure container thread pool to have smaller number of long liven threads ( longer TTL times to reduce churn). Is there a simple way to do it on jetty? On May 9, 2013, at 10:28 PM, Erick Erickson erickerick...@gmail.com wrote: Adrien: Yeah, this is getting warmer. Some of the CompressingStoredFieldsReader objects are 240M. The documents aren't nearly that large I don't think (but I'll verify). But still, over 700 of these objects live at once? I _think_ I'm seeing the number go up significantly when the number of indexing threads increases, but that's a bit of indirect evidence. My other question would be whether you'd expect the number of these objects to go up as the number of segments goes up, i.e. I assume they're per-segment So the pattern here is atomic updates on documents where some of the fields get quite large. So the underlying reader has to decompress these a lot. Do you have any suggestions how to mitigate this? Other than don't do thatG Thanks, Erick On Thu, May 9, 2013 at 6:45 AM, Adrien Grand jpou...@gmail.com wrote: Hi Erick, The stored fields reader reuses the buffer used for decompression across calls in the same thread, so I'm thinking that this kind of behaviour could happen if some documents are very large. Is it the case? Adrien Le 8 mai 2013 17:22, Erick Erickson erickerick...@gmail.com a écrit : I'm seeing a case where (reported to me, not on my personal machine) where Solr's heap is being exhausted apparently by compressed field reader. Here's a sample line from a summary of a heap dump: CompressingStoredFieldReader 735 instances where the CompressingStoredFieldReader instances are taking up 7.5G of heap space (out of 8 allocated). The GC cycles are a pattern I've seen before gc for a long time, recover a few meg run for a _very_ short time gc again, recover a few meg This app happens to be doing a lot of atomic updates, running with CMS collector, java 1.7. There is very little querying going on, and it is happening on several different machines. Solr 4.2. Now, there is a bit of custom update code involved, we're testing whether 1 if not compressing the stored fields changes things 2 if disabling the custom code changes things 3 if Solr 4.3 changes things. 4 whether memory usage grows over time linearly or spikes (pretty sure the former). This is an index-heavy/query-light application, and we're hosing a _bunch_ of documents at the indexing process. But still, assuming that the memory reporting above is accurate, each CompressingStoredFieldReader is apparently taking up 10M each and there are over 700 of them. The documents are being batched (don't quite know how many per batch, will find out). Mainly, I'm asking if this rings any bells. I don't see anything on a quick look at the JIRAs. Thanks, Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4795) Sub shard leader should not accept any updates from parent after it goes active
[ https://issues.apache.org/jira/browse/SOLR-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653593#comment-13653593 ] Commit Tag Bot commented on SOLR-4795: -- [lucene_solr_4_3 commit] shalin http://svn.apache.org/viewvc?view=revisionrevision=1480895 SOLR-4795: Sub shard leader should not accept any updates from parent after it goes active Sub shard leader should not accept any updates from parent after it goes active --- Key: SOLR-4795 URL: https://issues.apache.org/jira/browse/SOLR-4795 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.3 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 4.4 Attachments: SOLR-4795.patch The sub shard leaders accept any update from a parent as long as their range is a subset of parent's range. A sub shard can continue to accept updates from parent even after it has gone active which can lead to inconsistencies. This affects partial updates (think counters) the most but can also lead to out-of-order updates to the same document. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4807) zkcli - log4j is not configured, so no logging happens
Shawn Heisey created SOLR-4807: -- Summary: zkcli - log4j is not configured, so no logging happens Key: SOLR-4807 URL: https://issues.apache.org/jira/browse/SOLR-4807 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.3 Reporter: Shawn Heisey Priority: Minor Fix For: 5.0, 4.4, 4.3.1 When executing the zkcli script from the 4.3.0 release, a log4j error message is displayed about no appenders, because there is no log4j configuration. As a result of this problem, none of the normal zkcli stuff gets logged. A minimal config needs to be present so that it behaves like it did before the logging change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4807) zkcli - log4j is not configured, so no logging happens
[ https://issues.apache.org/jira/browse/SOLR-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey reassigned SOLR-4807: -- Assignee: Shawn Heisey zkcli - log4j is not configured, so no logging happens -- Key: SOLR-4807 URL: https://issues.apache.org/jira/browse/SOLR-4807 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.3 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 5.0, 4.4, 4.3.1 When executing the zkcli script from the 4.3.0 release, a log4j error message is displayed about no appenders, because there is no log4j configuration. As a result of this problem, none of the normal zkcli stuff gets logged. A minimal config needs to be present so that it behaves like it did before the logging change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4807) zkcli - log4j is not configured, so no logging happens
[ https://issues.apache.org/jira/browse/SOLR-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653595#comment-13653595 ] Shawn Heisey commented on SOLR-4807: Fix Version/s includes 4.3.1, as this will probably be a small and safe fix. zkcli - log4j is not configured, so no logging happens -- Key: SOLR-4807 URL: https://issues.apache.org/jira/browse/SOLR-4807 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.3 Reporter: Shawn Heisey Priority: Minor Fix For: 5.0, 4.4, 4.3.1 When executing the zkcli script from the 4.3.0 release, a log4j error message is displayed about no appenders, because there is no log4j configuration. As a result of this problem, none of the normal zkcli stuff gets logged. A minimal config needs to be present so that it behaves like it did before the logging change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4807) zkcli - log4j is not configured, so no logging happens
[ https://issues.apache.org/jira/browse/SOLR-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653599#comment-13653599 ] Shawn Heisey commented on SOLR-4807: I've assigned the issue to myself, but anyone who wants it is free to take it. zkcli - log4j is not configured, so no logging happens -- Key: SOLR-4807 URL: https://issues.apache.org/jira/browse/SOLR-4807 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.3 Reporter: Shawn Heisey Assignee: Shawn Heisey Priority: Minor Fix For: 5.0, 4.4, 4.3.1 When executing the zkcli script from the 4.3.0 release, a log4j error message is displayed about no appenders, because there is no log4j configuration. As a result of this problem, none of the normal zkcli stuff gets logged. A minimal config needs to be present so that it behaves like it did before the logging change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4798) shard splitting does not respect router (docs with a compositeId may not go to correct shard)
[ https://issues.apache.org/jira/browse/SOLR-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653598#comment-13653598 ] Commit Tag Bot commented on SOLR-4798: -- [lucene_solr_4_3 commit] shalin http://svn.apache.org/viewvc?view=revisionrevision=1480897 SOLR-4798: use correct router during index splitting shard splitting does not respect router (docs with a compositeId may not go to correct shard) - Key: SOLR-4798 URL: https://issues.apache.org/jira/browse/SOLR-4798 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.3 Reporter: Yonik Seeley Assignee: Yonik Seeley Fix For: 4.3.1 Attachments: SOLR-4798.patch Lowest level shard splitting code needs to somehow use the router for the collection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4797) Sub shards have wrong hash range in cluster state except when using PlainIdRouter
[ https://issues.apache.org/jira/browse/SOLR-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653604#comment-13653604 ] Commit Tag Bot commented on SOLR-4797: -- [lucene_solr_4_3 commit] shalin http://svn.apache.org/viewvc?view=revisionrevision=1480898 SOLR-4797: Shard splitting creates sub shards which have the wrong hash range in cluster state. This happens when numShards is not a power of two and router is compositeId Sub shards have wrong hash range in cluster state except when using PlainIdRouter - Key: SOLR-4797 URL: https://issues.apache.org/jira/browse/SOLR-4797 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.3 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 4.3.1 Attachments: SOLR-4797.patch The overseer collection processor always uses PlainIdRouter to partition the hash range. However, some router implementations (most notably CompositeIdRouter) can provide a different implementation to partition hash ranges. So there can be a mismatch between the hash ranges which are persisted in clusterstate.xml for sub shards and the actual index which is split using the collection's configured router impl. This bug does not affect collections using PlainIdRouter. The overseer collection processor should always use the collection's configured router to partition ranges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4791) solr.xml sharedLib does not work in 4.3.0
[
https://issues.apache.org/jira/browse/SOLR-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653608#comment-13653608
]
Shalin Shekhar Mangar commented on SOLR-4791:
-
Is there anything left here? Can I backport the commits to 4.3.1?
solr.xml sharedLib does not work in 4.3.0
-
Key: SOLR-4791
URL: https://issues.apache.org/jira/browse/SOLR-4791
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.3
Reporter: Jan Høydahl
Assignee: Erick Erickson
Fix For: 5.0, 4.4, 4.3.1
Attachments: closeLoader.patch, SOLR-4791.patch, SOLR-4791.patch,
SOLR-4791.patch, SOLR-4791-test.patch
The sharedLib attribute on {{solr}} tag in solr.xml stopped working in 4.3.
Using old-style solr.xml with sharedLib defined on solr tag. Solr does not
load any of them. Simply swapping out solr.war with the 4.2.1 one, brings
sharedLib loading back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4995) Remove the strong reference of CompressingStoredFieldsReader on the decompression buffer
Adrien Grand created LUCENE-4995: Summary: Remove the strong reference of CompressingStoredFieldsReader on the decompression buffer Key: LUCENE-4995 URL: https://issues.apache.org/jira/browse/LUCENE-4995 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand CompressingStoredFieldsReader has a strong reference on the buffer it uses for decompression. Although it makes the reader able to reuse this buffer, this can trigger high memory usage in case some documents are very large. Creating this buffer on demand would help give memory back to the JVM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4995) Remove the strong reference of CompressingStoredFieldsReader on the decompression buffer
[ https://issues.apache.org/jira/browse/LUCENE-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-4995: - Attachment: LUCENE-4995.patch Patch. CompressingTermVectorsReader doesn't need the fix since it already creates the decompression buffer on demand. Remove the strong reference of CompressingStoredFieldsReader on the decompression buffer Key: LUCENE-4995 URL: https://issues.apache.org/jira/browse/LUCENE-4995 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-4995.patch CompressingStoredFieldsReader has a strong reference on the buffer it uses for decompression. Although it makes the reader able to reuse this buffer, this can trigger high memory usage in case some documents are very large. Creating this buffer on demand would help give memory back to the JVM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Compressed field reader and memory problems with atomic updates
Erick, On Thu, May 9, 2013 at 10:28 PM, Erick Erickson erickerick...@gmail.com wrote: Yeah, this is getting warmer. Some of the CompressingStoredFieldsReader objects are 240M. The documents aren't nearly that large I don't think (but I'll verify). Wow, 240M is a lot! Would you be able to know which member of these instances is making them so large? Since you were mentioning threading, I first thought that the culprit was the buffer used for decompression but it could be the fields index as well (which is stored in memory but should be shared across instances for the same segment, so threading shouldn't make the situation worse). But still, over 700 of these objects live at once? I _think_ I'm seeing the number go up significantly when the number of indexing threads increases, but that's a bit of indirect evidence. My other question would be whether you'd expect the number of these objects to go up as the number of segments goes up, i.e. I assume they're per-segment Indeed, these objects are managed per-segment, so increasing the number of segments increases the number of stored fields reader instances. So the pattern here is atomic updates on documents where some of the fields get quite large. So the underlying reader has to decompress these a lot. Do you have any suggestions how to mitigate this? Other than don't do thatG As Savia suggests, lowering the number of indexing threads should help. If the merge factor is highish, lowering it could help as well. On my end, I'll fix the stored fields reader to not reuse the buffer for decompression (https://issues.apache.org/jira/browse/LUCENE-4995, even if we find out that it is not the problem here, it shouldn't hurt). -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Sorry for JIRA mails
In the past we always pushed that version forward, which is what I did. Steven Rowe did this the last time in January (4.1-4.2), also spamming the mailing list - so I am not the first one. JIRA 5.2 is just missing the suppress email, so you have to do the change in 2 steps: - Do a bulk change with suppressed emails - set version to released I updated the wiki with the warning about the risk of spamming the mailing list. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Friday, May 10, 2013 8:06 AM To: dev@lucene.apache.org Subject: Re: Sorry for JIRA mails I found out that Lucene/Solr 4.3 was not marked as released version in JIRA. I e-mailed about it 2 days ago but wasn't sure what to do with it. http://goo.gl/xXhgF D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4993) BeiderMorseFilter inserts tokens with positionIncrement=0, but ignores all custom attributes except OffsetAttribute
[ https://issues.apache.org/jira/browse/LUCENE-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653627#comment-13653627 ] Commit Tag Bot commented on LUCENE-4993: [trunk commit] uschindler http://svn.apache.org/viewvc?view=revisionrevision=1480911 LUCENE-4993: Fix BeiderMorseFilter to preserve custom attributes when inserting tokens with position increment 0. BeiderMorseFilter inserts tokens with positionIncrement=0, but ignores all custom attributes except OffsetAttribute --- Key: LUCENE-4993 URL: https://issues.apache.org/jira/browse/LUCENE-4993 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: 4.3 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Trivial Fix For: 4.4 Attachments: LUCENE-4993.patch BeiderMorseFilter inserts sometimes additional phonetic tokens for the same source token. Currently it calls clearAttributes before doing this and sets the new token's term, positionIncrement=0 and the original offset. This leads to problems if the TokenStream contains other attributes inserted before (like KeywordAttribute, FlagsAttribute,...). Those are all reverted to defaults for the inserted tokens. The TokenFilter should remove the special case done for preserving offsets and instead to captureState() and restoreState(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4993) BeiderMorseFilter inserts tokens with positionIncrement=0, but ignores all custom attributes except OffsetAttribute
[ https://issues.apache.org/jira/browse/LUCENE-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653628#comment-13653628 ] Commit Tag Bot commented on LUCENE-4993: [branch_4x commit] uschindler http://svn.apache.org/viewvc?view=revisionrevision=1480912 Merged revision(s) 1480911 from lucene/dev/trunk: LUCENE-4993: Fix BeiderMorseFilter to preserve custom attributes when inserting tokens with position increment 0. BeiderMorseFilter inserts tokens with positionIncrement=0, but ignores all custom attributes except OffsetAttribute --- Key: LUCENE-4993 URL: https://issues.apache.org/jira/browse/LUCENE-4993 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: 4.3 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Trivial Fix For: 4.4 Attachments: LUCENE-4993.patch BeiderMorseFilter inserts sometimes additional phonetic tokens for the same source token. Currently it calls clearAttributes before doing this and sets the new token's term, positionIncrement=0 and the original offset. This leads to problems if the TokenStream contains other attributes inserted before (like KeywordAttribute, FlagsAttribute,...). Those are all reverted to defaults for the inserted tokens. The TokenFilter should remove the special case done for preserving offsets and instead to captureState() and restoreState(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4993) BeiderMorseFilter inserts tokens with positionIncrement=0, but ignores all custom attributes except OffsetAttribute
[ https://issues.apache.org/jira/browse/LUCENE-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-4993. --- Resolution: Fixed Fix Version/s: 5.0 BeiderMorseFilter inserts tokens with positionIncrement=0, but ignores all custom attributes except OffsetAttribute --- Key: LUCENE-4993 URL: https://issues.apache.org/jira/browse/LUCENE-4993 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: 4.3 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Trivial Fix For: 5.0, 4.4 Attachments: LUCENE-4993.patch BeiderMorseFilter inserts sometimes additional phonetic tokens for the same source token. Currently it calls clearAttributes before doing this and sets the new token's term, positionIncrement=0 and the original offset. This leads to problems if the TokenStream contains other attributes inserted before (like KeywordAttribute, FlagsAttribute,...). Those are all reverted to defaults for the inserted tokens. The TokenFilter should remove the special case done for preserving offsets and instead to captureState() and restoreState(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4994) PatternKeywordMarkerFilter is final and has protected ctor and cannot be instantiated by non-Lucene code
[ https://issues.apache.org/jira/browse/LUCENE-4994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4994: -- Fix Version/s: 5.0 PatternKeywordMarkerFilter is final and has protected ctor and cannot be instantiated by non-Lucene code Key: LUCENE-4994 URL: https://issues.apache.org/jira/browse/LUCENE-4994 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: 4.3 Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 5.0, 4.4 I tried to write a test for LUCENE-4993 but recognized that a copy'n'paste error made the ctor of this filter protected. The sister SetKeywordMarkerFilter has public ctor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b86) - Build # 5582 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5582/
Java: 64bit/jdk1.8.0-ea-b86 -XX:-UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED:
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains
{#6 seed=[2301AA95F732FAE3:A9AE9291D68A1C44]}
Error Message:
Shouldn't match I #4:ShapePair(Rect(minX=15.0,maxX=28.0,minY=-107.0,maxY=97.0)
, Rect(minX=146.0,maxX=165.0,minY=-100.0,maxY=56.0))
Q:Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0)
Stack Trace:
java.lang.AssertionError: Shouldn't match I
#4:ShapePair(Rect(minX=15.0,maxX=28.0,minY=-107.0,maxY=97.0) ,
Rect(minX=146.0,maxX=165.0,minY=-100.0,maxY=56.0))
Q:Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0)
at
__randomizedtesting.SeedInfo.seed([2301AA95F732FAE3:A9AE9291D68A1C44]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.fail(SpatialOpRecursivePrefixTreeTest.java:287)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.doTest(SpatialOpRecursivePrefixTreeTest.java:273)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains(SpatialOpRecursivePrefixTreeTest.java:101)
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:490)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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
[jira] [Commented] (SOLR-3862) add remove as update option for atomically removing a value from a multivalued field
[ https://issues.apache.org/jira/browse/SOLR-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653660#comment-13653660 ] Andreas Kleiber commented on SOLR-3862: --- I need this aswell. We have a message based system to generate / update our solr index. So an option to remove an entry of a multiValued field by value is very nice. I would appreciate if this will be merged. add remove as update option for atomically removing a value from a multivalued field -- Key: SOLR-3862 URL: https://issues.apache.org/jira/browse/SOLR-3862 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA Reporter: Jim Musil Attachments: SOLR-3862.patch Currently you can atomically add a value to a multivalued field. It would be useful to be able to remove a value from a multivalued field. When you set a multivalued field to null, it destroys all values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make tests.failfast default to true
I don't have any strong opinion, to be honest so if nobody vetoes this
change, go ahead.
Dawid
On Fri, May 10, 2013 at 8:27 AM, Shai Erera ser...@gmail.com wrote:
I thought to make the change in LuceneTestCase.
Shai
On Fri, May 10, 2013 at 8:56 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl
wrote:
I don't care much. If you do though, you can specify your own override
in any of these locations?
property file=${user.home}/lucene.build.properties/
property file=${user.home}/build.properties/
property file=${basedir}/build.properties/
property file=${common.dir}/build.properties/
Or is this something you'd like to promote to the top level?
Dawid
On Fri, May 10, 2013 at 7:20 AM, Shai Erera ser...@gmail.com wrote:
Hi
Can we default tests.failfast to true? I don't know how common it is to
run
with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to see
all
N tests finish.
At any rate, if someone wishes to, he can always specify
-Dtests.failfast=false. It now depends what is the default behavior we
want
to have.
Any thoughts?
Shai
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4975) Add Replication module to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653896#comment-13653896 ] Shai Erera commented on LUCENE-4975: I ran both tests w/ tests.iters=1000 and they passed. This gives me more confidence about the robustness of these two handlers. Still, other machines can dig up special seeds :). Add Replication module to Lucene Key: LUCENE-4975 URL: https://issues.apache.org/jira/browse/LUCENE-4975 Project: Lucene - Core Issue Type: New Feature Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch I wrote a replication module which I think will be useful to Lucene users who want to replicate their indexes for e.g high-availability, taking hot backups etc. I will upload a patch soon where I'll describe in general how it works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-4975) Add Replication module to Lucene
[
https://issues.apache.org/jira/browse/LUCENE-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653562#comment-13653562
]
Shai Erera edited comment on LUCENE-4975 at 5/10/13 10:34 AM:
--
Patch resolves all remaining noocmmits. I made both IndexReplicationHandler and
IndexAndTaxonomyReplicationHandler more resilient to errors but carefully
reverting any changes made to the target indexes on errors. Also ensure that
segments_N files are written last.
I also added code to write segments.gen. To do that I factored out
SegmentInfos.writeSegmentsGen which takes a Directory and generation. It is now
used by SIS.finishCommit and the handlers.
Would appreciate if someone can review the handlers, and whether they can be
written in a more resilient ways.
I want to beast IndexReplicationClientTest and
IndexAndTaxonomyReplictionClientTest checkConsistencyOnExceptions before
committing. If anyone's interested to help, just fire {{ant test
-Dtestcase=IndexReplicationClientTest
-Dtestsm.method=testConsistencyOnExceptions -Dtests.iters=1000}} (and same for
IndexAndTaxonomyReplicationClientTest) and let me know the seeds that failed.
was (Author: shaie):
Patch resolves all remaining noocmmits. I made both IndexReplicationHandler
and IndexAndTaxonomyReplicationHandler more resilient to errors but carefully
reverting any changes made to the target indexes on errors. Also ensure that
segments_N files are written last.
I also added code to write segments.gen. To do that I factored out
SegmentInfos.writeSegmentsGen which takes a Directory and generation. It is now
used by SIS.finishCommit and the handlers.
Would appreciate if someone can review the handlers, and whether they can be
written in a more resilient ways.
I want to beast IndexReplicationClientTest and
IndexAndTaxonomyReplictionClientTest checkConsistencyOnExceptions before
committing. If anyone's interested to help, just fire {{ant test
-Dtestcase=IndexReplicationHandlerTest
-Dtestsm.method=testConsistencyOnExceptions -Dtests.iters=1000}} (and same for
IndexAndTaxonomyReplicationClientTest) and let me know the seeds that failed.
Add Replication module to Lucene
Key: LUCENE-4975
URL: https://issues.apache.org/jira/browse/LUCENE-4975
Project: Lucene - Core
Issue Type: New Feature
Reporter: Shai Erera
Assignee: Shai Erera
Attachments: LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch,
LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch
I wrote a replication module which I think will be useful to Lucene users who
want to replicate their indexes for e.g high-availability, taking hot backups
etc.
I will upload a patch soon where I'll describe in general how it works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4791) solr.xml sharedLib does not work in 4.3.0
[
https://issues.apache.org/jira/browse/SOLR-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654369#comment-13654369
]
Erick Erickson commented on SOLR-4791:
--
Go for it. Be sure to apply both the SOLR-4791.patch and closeLoader.patch.
They were originally applied in that order, but I doubt it matters.
solr.xml sharedLib does not work in 4.3.0
-
Key: SOLR-4791
URL: https://issues.apache.org/jira/browse/SOLR-4791
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.3
Reporter: Jan Høydahl
Assignee: Erick Erickson
Fix For: 5.0, 4.4, 4.3.1
Attachments: closeLoader.patch, SOLR-4791.patch, SOLR-4791.patch,
SOLR-4791.patch, SOLR-4791-test.patch
The sharedLib attribute on {{solr}} tag in solr.xml stopped working in 4.3.
Using old-style solr.xml with sharedLib defined on solr tag. Solr does not
load any of them. Simply swapping out solr.war with the 4.2.1 one, brings
sharedLib loading back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4791) solr.xml sharedLib does not work in 4.3.0
[
https://issues.apache.org/jira/browse/SOLR-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-4791.
--
Resolution: Fixed
Haven't seen any test failures since Robert added the patch so I'm marking this
resolved.
solr.xml sharedLib does not work in 4.3.0
-
Key: SOLR-4791
URL: https://issues.apache.org/jira/browse/SOLR-4791
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.3
Reporter: Jan Høydahl
Assignee: Erick Erickson
Fix For: 5.0, 4.4, 4.3.1
Attachments: closeLoader.patch, SOLR-4791.patch, SOLR-4791.patch,
SOLR-4791.patch, SOLR-4791-test.patch
The sharedLib attribute on {{solr}} tag in solr.xml stopped working in 4.3.
Using old-style solr.xml with sharedLib defined on solr tag. Solr does not
load any of them. Simply swapping out solr.war with the 4.2.1 one, brings
sharedLib loading back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Code checkin, vacation and reverting
I'll be checking in a pretty small patch today (SOLR-4790) (assuming all tests pass) and then leaving for vacation. I hereby pre-authorize anyone at all to revert it if it's a problem. Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654379#comment-13654379
]
Jan Høydahl commented on SOLR-4760:
---
I get a nullpointer caused by this patch, when running tests for a patch.
{noformat}
[junit4:junit4] 2 NOTE: All tests run in this JVM: [TestMaxScoreQueryParser]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestMaxScoreQueryParser -Dtests.seed=FFA2D62653D3F0F3
-Dtests.slow=true -Dtests.locale=nl_BE -Dtests.timezone=America/Shiprock
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | TestMaxScoreQueryParser (suite)
[junit4:junit4] Throwable #1: org.apache.solr.common.SolrException: Schema
Parsing Failed: null
[junit4:junit4]at
__randomizedtesting.SeedInfo.seed([FFA2D62653D3F0F3]:0)
[junit4:junit4]at
org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:607)
[junit4:junit4]at
org.apache.solr.schema.IndexSchema.init(IndexSchema.java:166)
[junit4:junit4]at
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:55)
[junit4:junit4]at
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:69)
[junit4:junit4]at
org.apache.solr.util.TestHarness.init(TestHarness.java:108)
[junit4:junit4]at
org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:393)
[junit4:junit4]at
org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:385)
[junit4:junit4]at
org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:197)
[junit4:junit4]at
org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:184)
[junit4:junit4]at
org.apache.solr.search.TestMaxScoreQueryParser.beforeClass(TestMaxScoreQueryParser.java:36)
[junit4:junit4]at java.lang.Thread.run(Thread.java:722)
[junit4:junit4] Caused by: java.lang.NullPointerException
[junit4:junit4]at
org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:437)
[junit4:junit4]... 32 more
[junit4:junit4] Completed in 2.16s, 0 tests, 1 error FAILURES!
{noformat}
The offending line is:
{code:java}
437: sb.append(loader.getCoreProperties().getProperty(NAME));
{code}
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Compressed field reader and memory problems with atomic updates
Thanks to you both. I've pinged the people who can reproduce this problem, I suspect they'll try the patch out. I'm out next week, far far away from internet connections so I'll be silent for a while. But don't be surprised if new messages appear. Thanks again Erick On Fri, May 10, 2013 at 3:46 AM, Adrien Grand jpou...@gmail.com wrote: Erick, On Thu, May 9, 2013 at 10:28 PM, Erick Erickson erickerick...@gmail.com wrote: Yeah, this is getting warmer. Some of the CompressingStoredFieldsReader objects are 240M. The documents aren't nearly that large I don't think (but I'll verify). Wow, 240M is a lot! Would you be able to know which member of these instances is making them so large? Since you were mentioning threading, I first thought that the culprit was the buffer used for decompression but it could be the fields index as well (which is stored in memory but should be shared across instances for the same segment, so threading shouldn't make the situation worse). But still, over 700 of these objects live at once? I _think_ I'm seeing the number go up significantly when the number of indexing threads increases, but that's a bit of indirect evidence. My other question would be whether you'd expect the number of these objects to go up as the number of segments goes up, i.e. I assume they're per-segment Indeed, these objects are managed per-segment, so increasing the number of segments increases the number of stored fields reader instances. So the pattern here is atomic updates on documents where some of the fields get quite large. So the underlying reader has to decompress these a lot. Do you have any suggestions how to mitigate this? Other than don't do thatG As Savia suggests, lowering the number of indexing threads should help. If the merge factor is highish, lowering it could help as well. On my end, I'll fix the stored fields reader to not reuse the buffer for decompression (https://issues.apache.org/jira/browse/LUCENE-4995, even if we find out that it is not the problem here, it shouldn't hurt). -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reopened SOLR-4760:
---
Reopening to examine the nullpointer
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4018) Dispatcher to optionally write QTime and Hits HTTP header
[
https://issues.apache.org/jira/browse/SOLR-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-4018:
Attachment: SOLR-4018-trunk-5.patch
Updated patch for trunk.
Dispatcher to optionally write QTime and Hits HTTP header
-
Key: SOLR-4018
URL: https://issues.apache.org/jira/browse/SOLR-4018
Project: Solr
Issue Type: Improvement
Affects Versions: 4.0
Reporter: Markus Jelsma
Fix For: 4.4
Attachments: SOLR-4018-trunk-1.patch, SOLR-4018-trunk-2.patch,
SOLR-4018-trunk-3.patch, SOLR-4018-trunk-4.patch, SOLR-4018-trunk-5.patch
SolrDispatchFilter should be able to write QTime and Hits HTTP headers via
configuration.
{code}
requestDispatcher handleSelect=true
requestParsers enableRemoteStreaming=false
multipartUploadLimitInKB=2048000 /
httpCaching never304=true /
httpHeaders qtime=true hits=true/
/requestDispatcher
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654393#comment-13654393
]
Erick Erickson commented on SOLR-4760:
--
right, I'm seeing the same thing:
sb.append(loader.getCoreProperties().getProperty(NAME));
getCoreProperties returns null here. Seems like a simple if test here would
suffice, are you taking care of it or should I? I've seen several situations
where stuff is null (particularly CoreContainer.cfg) in the test environment
that are _never_ null in non-test, this could be another one of those.
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654397#comment-13654397
]
Jan Høydahl commented on SOLR-4760:
---
Yea, a test issue probably. Not sure why I bump into it only in the tests.
I tried to copy core.properties into collection1/ in test-files, but that did
not help either. Must be that test framework does not initialize same way as
the real thing.
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4975) Add Replication module to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-4975: --- Attachment: LUCENE-4975.patch Mike found a seed which tripped a test bug. Fixed it and on the way made the test less sensitive to time changes (i.e. it waited up to 20 seconds for the index to get updated, otherwise failed) and added some other improvements (to the test only). Let's search for more seeds :). Add Replication module to Lucene Key: LUCENE-4975 URL: https://issues.apache.org/jira/browse/LUCENE-4975 Project: Lucene - Core Issue Type: New Feature Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch I wrote a replication module which I think will be useful to Lucene users who want to replicate their indexes for e.g high-availability, taking hot backups etc. I will upload a patch soon where I'll describe in general how it works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654401#comment-13654401
]
Jan Høydahl commented on SOLR-4760:
---
This patch did the trick for me
{code}
437: sb.append(loader.getCoreProperties()!=null ?
loader.getCoreProperties().getProperty(NAME) : (N/A));
{code}
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654402#comment-13654402
]
Erick Erickson commented on SOLR-4760:
--
yep, that's what I've found viz. some of the stuff in CoreContainer, you'll see
some if tests in there (which I hate but haven't had a chance to track down).
I'll take care of it. I think this is useful information in the usual case,
simple if test. Look for a patch soon.
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4975) Add Replication module to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-4975: --- Attachment: LUCENE-4975.patch Forgot to include one change -- handleUpdateEx should fail if the exception it hits is not IOE. Previous patch called super.handle(), which only logged it. But I think it's fair to say that the test shouldn't hit any exception, and terminate the client if it does. Add Replication module to Lucene Key: LUCENE-4975 URL: https://issues.apache.org/jira/browse/LUCENE-4975 Project: Lucene - Core Issue Type: New Feature Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch I wrote a replication module which I think will be useful to Lucene users who want to replicate their indexes for e.g high-availability, taking hot backups etc. I will upload a patch soon where I'll describe in general how it works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654405#comment-13654405
]
Commit Tag Bot commented on SOLR-4751:
--
[trunk commit] koji
http://svn.apache.org/viewvc?view=revisionrevision=1480988
SOLR-4751: fix replication problem of files in sub directory of conf
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4995) Remove the strong reference of CompressingStoredFieldsReader on the decompression buffer
[ https://issues.apache.org/jira/browse/LUCENE-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654414#comment-13654414 ] Robert Muir commented on LUCENE-4995: - Are we sure this is the right thing to do? People have misconfigured threadpools (especially tomcat users) and complain all the time about e.g. the analyzer buffers and so on. I just want to make sure these misconfigured users arent causing correctly-configured users massive amounts of garbage etc. Remove the strong reference of CompressingStoredFieldsReader on the decompression buffer Key: LUCENE-4995 URL: https://issues.apache.org/jira/browse/LUCENE-4995 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-4995.patch CompressingStoredFieldsReader has a strong reference on the buffer it uses for decompression. Although it makes the reader able to reuse this buffer, this can trigger high memory usage in case some documents are very large. Creating this buffer on demand would help give memory back to the JVM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make tests.failfast default to true
why change it? On Fri, May 10, 2013 at 1:20 AM, Shai Erera ser...@gmail.com wrote: Hi Can we default tests.failfast to true? I don't know how common it is to run with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to see all N tests finish. At any rate, if someone wishes to, he can always specify -Dtests.failfast=false. It now depends what is the default behavior we want to have. Any thoughts? Shai
[jira] [Commented] (SOLR-4563) RSS DIH-example not working
[ https://issues.apache.org/jira/browse/SOLR-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654421#comment-13654421 ] Commit Tag Bot commented on SOLR-4563: -- [trunk commit] janhoy http://svn.apache.org/viewvc?view=revisionrevision=1480993 SOLR-4563: RSS DIH-example not working RSS DIH-example not working --- Key: SOLR-4563 URL: https://issues.apache.org/jira/browse/SOLR-4563 Project: Solr Issue Type: Bug Affects Versions: 4.2 Reporter: Jan Høydahl Fix For: 4.4 Attachments: SOLR-4563.patch The xpath paths of /rss/item do not match the real world RSS feed which uses /rss/channel/item -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4791) solr.xml sharedLib does not work in 4.3.0
[
https://issues.apache.org/jira/browse/SOLR-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654423#comment-13654423
]
Robert Muir commented on SOLR-4791:
---
shouldn't this have a changes entry?
solr.xml sharedLib does not work in 4.3.0
-
Key: SOLR-4791
URL: https://issues.apache.org/jira/browse/SOLR-4791
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.3
Reporter: Jan Høydahl
Assignee: Erick Erickson
Fix For: 5.0, 4.4, 4.3.1
Attachments: closeLoader.patch, SOLR-4791.patch, SOLR-4791.patch,
SOLR-4791.patch, SOLR-4791-test.patch
The sharedLib attribute on {{solr}} tag in solr.xml stopped working in 4.3.
Using old-style solr.xml with sharedLib defined on solr tag. Solr does not
load any of them. Simply swapping out solr.war with the 4.2.1 one, brings
sharedLib loading back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4563) RSS DIH-example not working
[ https://issues.apache.org/jira/browse/SOLR-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654424#comment-13654424 ] Commit Tag Bot commented on SOLR-4563: -- [branch_4x commit] janhoy http://svn.apache.org/viewvc?view=revisionrevision=1480994 SOLR-4563: RSS DIH-example not working (backport) RSS DIH-example not working --- Key: SOLR-4563 URL: https://issues.apache.org/jira/browse/SOLR-4563 Project: Solr Issue Type: Bug Affects Versions: 4.2 Reporter: Jan Høydahl Fix For: 4.4 Attachments: SOLR-4563.patch The xpath paths of /rss/item do not match the real world RSS feed which uses /rss/channel/item -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4563) RSS DIH-example not working
[ https://issues.apache.org/jira/browse/SOLR-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-4563: -- Fix Version/s: 5.0 RSS DIH-example not working --- Key: SOLR-4563 URL: https://issues.apache.org/jira/browse/SOLR-4563 Project: Solr Issue Type: Bug Affects Versions: 4.2 Reporter: Jan Høydahl Fix For: 5.0, 4.4 Attachments: SOLR-4563.patch The xpath paths of /rss/item do not match the real world RSS feed which uses /rss/channel/item -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4563) RSS DIH-example not working
[ https://issues.apache.org/jira/browse/SOLR-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-4563: -- Component/s: contrib - DataImportHandler RSS DIH-example not working --- Key: SOLR-4563 URL: https://issues.apache.org/jira/browse/SOLR-4563 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.2 Reporter: Jan Høydahl Fix For: 5.0, 4.4 Attachments: SOLR-4563.patch The xpath paths of /rss/item do not match the real world RSS feed which uses /rss/channel/item -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4563) RSS DIH-example not working
[ https://issues.apache.org/jira/browse/SOLR-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-4563: - Assignee: Jan Høydahl RSS DIH-example not working --- Key: SOLR-4563 URL: https://issues.apache.org/jira/browse/SOLR-4563 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.2 Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 5.0, 4.4 Attachments: SOLR-4563.patch The xpath paths of /rss/item do not match the real world RSS feed which uses /rss/channel/item -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4563) RSS DIH-example not working
[ https://issues.apache.org/jira/browse/SOLR-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-4563. --- Resolution: Fixed RSS DIH-example not working --- Key: SOLR-4563 URL: https://issues.apache.org/jira/browse/SOLR-4563 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.2 Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 5.0, 4.4 Attachments: SOLR-4563.patch The xpath paths of /rss/item do not match the real world RSS feed which uses /rss/channel/item -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
disable solr jenkins tasks?
I've noticed that nearly all solr tests (225 tests failing) have been failing for hours in jenkins. I have serious doubts whether any solr committers are even looking at test failures. Can we disable solr jobs in jenkins so that lucene gets more test coverage? Thanks, Robert
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654429#comment-13654429
]
Commit Tag Bot commented on SOLR-4760:
--
[trunk commit] erick
http://svn.apache.org/viewvc?view=revisionrevision=1480998
Test fix for SOLR-4760
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654435#comment-13654435
]
Commit Tag Bot commented on SOLR-4760:
--
[branch_4x commit] erick
http://svn.apache.org/viewvc?view=revisionrevision=1481003
Test fix for SOLR-4760
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654436#comment-13654436
]
Erick Erickson commented on SOLR-4760:
--
trunk: r - 1480998
4x:r - 1481003
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654455#comment-13654455
]
Commit Tag Bot commented on SOLR-4751:
--
[branch_4x commit] koji
http://svn.apache.org/viewvc?view=revisionrevision=1481004
SOLR-4751: fix replication problem of files in sub directory of conf
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-4760:
-
Attachment: SOLR-4760-testfix.patch
Patch for making the tests run, apply on top of original patch.
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch, SOLR-4760-testfix.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-4760.
--
Resolution: Fixed
Added null test so this doesn't break the tests.
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch, SOLR-4760-testfix.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make tests.failfast default to true
Because I think it makes more sense as a default? Usually when I run with tests.iters, I just search for a seed that fails. When I find it, I go fix the bug and run again. But that's just me. That's why I asked if others think it makes sense as a default too. There is no functionality change, just different default. Shai On May 10, 2013 3:33 PM, Robert Muir rcm...@gmail.com wrote: why change it? On Fri, May 10, 2013 at 1:20 AM, Shai Erera ser...@gmail.com wrote: Hi Can we default tests.failfast to true? I don't know how common it is to run with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to see all N tests finish. At any rate, if someone wishes to, he can always specify -Dtests.failfast=false. It now depends what is the default behavior we want to have. Any thoughts? Shai
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654460#comment-13654460
]
Commit Tag Bot commented on SOLR-4751:
--
[lucene_solr_4_3 commit] koji
http://svn.apache.org/viewvc?view=revisionrevision=1481008
SOLR-4751: fix replication problem of files in sub directory of conf
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654461#comment-13654461
]
Koji Sekiguchi commented on SOLR-4751:
--
I committed the patch on trunk, branch_4x and 4.3.
Osuka-san, can you check one of them and see that your fix can solve the
problem?
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-4751:
-
Fix Version/s: 4.4
5.0
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 5.0, 4.4
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4996) DocInverterPerField to log which field throws exceptions
Markus Jelsma created LUCENE-4996: - Summary: DocInverterPerField to log which field throws exceptions Key: LUCENE-4996 URL: https://issues.apache.org/jira/browse/LUCENE-4996 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Markus Jelsma Priority: Minor Fix For: 5.0, 4.4 One of ours fields seems to have a problem that didn't result in an exception before. It seems one of my filters doesn't deal with posIncAttr properly but Lucene did not log which of my numerous fields was the problem. This patch includes the field name in the exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654466#comment-13654466
]
Erick Erickson commented on SOLR-4760:
--
Gaaah. Removed the trailing ']' in the message by mistake. I'm not going to
re-spin the test-fix patch, but I'll fix it in another patch I'll put up
shortly.
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch, SOLR-4760-testfix.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4996) DocInverterPerField to log which field throws exceptions
[ https://issues.apache.org/jira/browse/LUCENE-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated LUCENE-4996: -- Attachment: LUCENE-4996-trunk.patch DocInverterPerField to log which field throws exceptions Key: LUCENE-4996 URL: https://issues.apache.org/jira/browse/LUCENE-4996 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Markus Jelsma Priority: Minor Fix For: 5.0, 4.4 Attachments: LUCENE-4996-trunk.patch One of ours fields seems to have a problem that didn't result in an exception before. It seems one of my filters doesn't deal with posIncAttr properly but Lucene did not log which of my numerous fields was the problem. This patch includes the field name in the exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654473#comment-13654473
]
Shawn Heisey commented on SOLR-4760:
[~janhoy] and [~erickerickson], many thanks for finding and fixing my mistake
while I slept. I did run tests and precommit back when I created this patch,
but I did not do so before the actual commit, which was sloppy.
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch, SOLR-4760-testfix.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1913) QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations on Integer Fields
[
https://issues.apache.org/jira/browse/SOLR-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deepthi Sigireddi updated SOLR-1913:
Attachment: SOLR-1913-src.tar.gz
Hi Israel,
I took the src you attached to the JIRA and migrated it to Solr 4.2.1. It
compiles now, and works as expected.
I haven't tried it with Solr 4.3, but presumably it will work fine with that
too.
I'm attaching a tar ball (SOLR-1913-src.tar.gz) with the modified source.
Ankur, Christopher, please feel free to try this out and give your feedback.
QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations
on Integer Fields
---
Key: SOLR-1913
URL: https://issues.apache.org/jira/browse/SOLR-1913
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Israel Ekpo
Fix For: 4.4
Attachments: bitwise_filter_plugin.jar, SOLR-1913.bitwise.tar.gz,
SOLR-1913-src.tar.gz
Original Estimate: 1h
Remaining Estimate: 1h
BitwiseQueryParserPlugin is a org.apache.solr.search.QParserPlugin that
allows
users to filter the documents returned from a query
by performing bitwise operations between a particular integer field in the
index
and the specified value.
This Solr plugin is based on the BitwiseFilter in LUCENE-2460
See https://issues.apache.org/jira/browse/LUCENE-2460 for more details
This is the syntax for searching in Solr:
http://localhost:8983/path/to/solr/select/?q={!bitwise field=fieldname
op=OPERATION_NAME source=sourcevalue negate=boolean}remainder of query
Example :
http://localhost:8983/solr/bitwise/select/?q={!bitwise field=user_permissions
op=AND source=3 negate=true}state:FL
The negate parameter is optional
The field parameter is the name of the integer field
The op parameter is the name of the operation; one of {AND, OR, XOR}
The source parameter is the specified integer value
The negate parameter is a boolean indicating whether or not to negate the
results of the bitwise operation
To test out this plugin, simply copy the jar file containing the plugin
classes into your $SOLR_HOME/lib directory and then
add the following to your solrconfig.xml file after the dismax request
handler:
queryParser name=bitwise
class=org.apache.solr.bitwise.BitwiseQueryParserPlugin basedOn=dismax /
Restart your servlet container.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4018) Dispatcher to optionally write QTime and Hits HTTP header
[
https://issues.apache.org/jira/browse/SOLR-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-4018:
Fix Version/s: 5.0
Dispatcher to optionally write QTime and Hits HTTP header
-
Key: SOLR-4018
URL: https://issues.apache.org/jira/browse/SOLR-4018
Project: Solr
Issue Type: Improvement
Affects Versions: 4.0
Reporter: Markus Jelsma
Fix For: 5.0, 4.4
Attachments: SOLR-4018-trunk-1.patch, SOLR-4018-trunk-2.patch,
SOLR-4018-trunk-3.patch, SOLR-4018-trunk-4.patch, SOLR-4018-trunk-5.patch
SolrDispatchFilter should be able to write QTime and Hits HTTP headers via
configuration.
{code}
requestDispatcher handleSelect=true
requestParsers enableRemoteStreaming=false
multipartUploadLimitInKB=2048000 /
httpCaching never304=true /
httpHeaders qtime=true hits=true/
/requestDispatcher
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654506#comment-13654506
]
Commit Tag Bot commented on SOLR-4760:
--
[lucene_solr_4_3 commit] erick
http://svn.apache.org/viewvc?view=revisionrevision=1481022
backporting test fix for SOLR-4760 to 4.3.1
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch, SOLR-4760-testfix.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654507#comment-13654507
]
Erick Erickson commented on SOLR-4760:
--
backported to 4.3.1, r: 1481022
Improve logging messages during startup to better identify core
---
Key: SOLR-4760
URL: https://issues.apache.org/jira/browse/SOLR-4760
Project: Solr
Issue Type: Wish
Components: Schema and Analysis
Affects Versions: 4.3
Reporter: Alexandre Rafalovitch
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4760.patch, SOLR-4760.patch, SOLR-4760-testfix.patch
Some log messages could be more informative. For example:
{code}
680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
schema has no name!
{code}
Would be _very nice_ to know which core this is complaining about.
Later, once the core is loaded, the core name shows up in the logs,
but it would be nice to have it earlier without having to
triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654515#comment-13654515
]
Commit Tag Bot commented on SOLR-4751:
--
[trunk commit] markrmiller
http://svn.apache.org/viewvc?view=revisionrevision=1481030
SOLR-4751: revert for now
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 5.0, 4.4
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654516#comment-13654516
]
Commit Tag Bot commented on SOLR-4751:
--
[branch_4x commit] markrmiller
http://svn.apache.org/viewvc?view=revisionrevision=1481031
SOLR-4751: revert for now
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 5.0, 4.4
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654517#comment-13654517
]
Mark Miller commented on SOLR-4751:
---
Seems a test fail is exposing an issue with this. I've reverted this for the
moment.
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 5.0, 4.4
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: disable solr jenkins tasks?
I've noticed that nearly all solr tests (225 tests failing) have been failing for hours in jenkins. I have serious doubts whether any solr committers are even looking at test failures. Can we disable solr jobs in jenkins so that lucene gets more test coverage? I will take a look when my commute ends and do my best to make some progress. Some of those failures were my fault on SOLR-4760. If the tests continue to fail, +1 to disabling. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4791) solr.xml sharedLib does not work in 4.3.0
[
https://issues.apache.org/jira/browse/SOLR-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654526#comment-13654526
]
Commit Tag Bot commented on SOLR-4791:
--
[trunk commit] erick
http://svn.apache.org/viewvc?view=revisionrevision=1481038
added to CHANGES.txt for SOLR-4791
solr.xml sharedLib does not work in 4.3.0
-
Key: SOLR-4791
URL: https://issues.apache.org/jira/browse/SOLR-4791
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.3
Reporter: Jan Høydahl
Assignee: Erick Erickson
Fix For: 5.0, 4.4, 4.3.1
Attachments: closeLoader.patch, SOLR-4791.patch, SOLR-4791.patch,
SOLR-4791.patch, SOLR-4791-test.patch
The sharedLib attribute on {{solr}} tag in solr.xml stopped working in 4.3.
Using old-style solr.xml with sharedLib defined on solr tag. Solr does not
load any of them. Simply swapping out solr.war with the 4.2.1 one, brings
sharedLib loading back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make tests.failfast default to true
I dont have any strong opinion really, i just want to mention on the side you can also change your 'personal defaults' by editing build.properties in your home directory too. On Fri, May 10, 2013 at 9:27 AM, Shai Erera ser...@gmail.com wrote: Because I think it makes more sense as a default? Usually when I run with tests.iters, I just search for a seed that fails. When I find it, I go fix the bug and run again. But that's just me. That's why I asked if others think it makes sense as a default too. There is no functionality change, just different default. Shai On May 10, 2013 3:33 PM, Robert Muir rcm...@gmail.com wrote: why change it? On Fri, May 10, 2013 at 1:20 AM, Shai Erera ser...@gmail.com wrote: Hi Can we default tests.failfast to true? I don't know how common it is to run with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to see all N tests finish. At any rate, if someone wishes to, he can always specify -Dtests.failfast=false. It now depends what is the default behavior we want to have. Any thoughts? Shai
Re: Make tests.failfast default to true
Thanks for the tip. If it's just me, I won't make the change. I just find it annoying to have to type it everytime, and think that this is probably what you intend to achieve when running w/ tests.iters -- search for a seed that trips the tests. If there are no objections, I'll make the trivial change later. Shai On Fri, May 10, 2013 at 5:55 PM, Robert Muir rcm...@gmail.com wrote: I dont have any strong opinion really, i just want to mention on the side you can also change your 'personal defaults' by editing build.properties in your home directory too. On Fri, May 10, 2013 at 9:27 AM, Shai Erera ser...@gmail.com wrote: Because I think it makes more sense as a default? Usually when I run with tests.iters, I just search for a seed that fails. When I find it, I go fix the bug and run again. But that's just me. That's why I asked if others think it makes sense as a default too. There is no functionality change, just different default. Shai On May 10, 2013 3:33 PM, Robert Muir rcm...@gmail.com wrote: why change it? On Fri, May 10, 2013 at 1:20 AM, Shai Erera ser...@gmail.com wrote: Hi Can we default tests.failfast to true? I don't know how common it is to run with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to see all N tests finish. At any rate, if someone wishes to, he can always specify -Dtests.failfast=false. It now depends what is the default behavior we want to have. Any thoughts? Shai
[jira] [Commented] (SOLR-4791) solr.xml sharedLib does not work in 4.3.0
[
https://issues.apache.org/jira/browse/SOLR-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654533#comment-13654533
]
Commit Tag Bot commented on SOLR-4791:
--
[lucene_solr_4_3 commit] erick
http://svn.apache.org/viewvc?view=revisionrevision=1481043
added to CHANGES.txt for SOLR-4791
solr.xml sharedLib does not work in 4.3.0
-
Key: SOLR-4791
URL: https://issues.apache.org/jira/browse/SOLR-4791
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.3
Reporter: Jan Høydahl
Assignee: Erick Erickson
Fix For: 5.0, 4.4, 4.3.1
Attachments: closeLoader.patch, SOLR-4791.patch, SOLR-4791.patch,
SOLR-4791.patch, SOLR-4791-test.patch
The sharedLib attribute on {{solr}} tag in solr.xml stopped working in 4.3.
Using old-style solr.xml with sharedLib defined on solr tag. Solr does not
load any of them. Simply swapping out solr.war with the 4.2.1 one, brings
sharedLib loading back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make tests.failfast default to true
I'm still hoping for the elusive tests.beast or whatever that gives each run a whole different seed and acts like the shellscripts that run 'ant test -Dtestcase' over and over :) On Fri, May 10, 2013 at 10:59 AM, Shai Erera ser...@gmail.com wrote: Thanks for the tip. If it's just me, I won't make the change. I just find it annoying to have to type it everytime, and think that this is probably what you intend to achieve when running w/ tests.iters -- search for a seed that trips the tests. If there are no objections, I'll make the trivial change later. Shai On Fri, May 10, 2013 at 5:55 PM, Robert Muir rcm...@gmail.com wrote: I dont have any strong opinion really, i just want to mention on the side you can also change your 'personal defaults' by editing build.properties in your home directory too. On Fri, May 10, 2013 at 9:27 AM, Shai Erera ser...@gmail.com wrote: Because I think it makes more sense as a default? Usually when I run with tests.iters, I just search for a seed that fails. When I find it, I go fix the bug and run again. But that's just me. That's why I asked if others think it makes sense as a default too. There is no functionality change, just different default. Shai On May 10, 2013 3:33 PM, Robert Muir rcm...@gmail.com wrote: why change it? On Fri, May 10, 2013 at 1:20 AM, Shai Erera ser...@gmail.com wrote: Hi Can we default tests.failfast to true? I don't know how common it is to run with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to see all N tests finish. At any rate, if someone wishes to, he can always specify -Dtests.failfast=false. It now depends what is the default behavior we want to have. Any thoughts? Shai
Re: Make tests.failfast default to true
Me too! :) I was hoping tests.dups would do it. Dawid promised me he will one day find the time to do it! :) In the meanwhile, Mike pointed me to repeatLuceneTest.py under luceneutil. I've yet been successful to run it, but I think it's just a matter of configuration. Maybe if you have a shellscript that's generic enough, it's worth putting under dev-tools? Shai On Fri, May 10, 2013 at 6:06 PM, Robert Muir rcm...@gmail.com wrote: I'm still hoping for the elusive tests.beast or whatever that gives each run a whole different seed and acts like the shellscripts that run 'ant test -Dtestcase' over and over :) On Fri, May 10, 2013 at 10:59 AM, Shai Erera ser...@gmail.com wrote: Thanks for the tip. If it's just me, I won't make the change. I just find it annoying to have to type it everytime, and think that this is probably what you intend to achieve when running w/ tests.iters -- search for a seed that trips the tests. If there are no objections, I'll make the trivial change later. Shai On Fri, May 10, 2013 at 5:55 PM, Robert Muir rcm...@gmail.com wrote: I dont have any strong opinion really, i just want to mention on the side you can also change your 'personal defaults' by editing build.properties in your home directory too. On Fri, May 10, 2013 at 9:27 AM, Shai Erera ser...@gmail.com wrote: Because I think it makes more sense as a default? Usually when I run with tests.iters, I just search for a seed that fails. When I find it, I go fix the bug and run again. But that's just me. That's why I asked if others think it makes sense as a default too. There is no functionality change, just different default. Shai On May 10, 2013 3:33 PM, Robert Muir rcm...@gmail.com wrote: why change it? On Fri, May 10, 2013 at 1:20 AM, Shai Erera ser...@gmail.com wrote: Hi Can we default tests.failfast to true? I don't know how common it is to run with -Dtests.iters=N, not specify -Dtests.maxfailures AND wanting to see all N tests finish. At any rate, if someone wishes to, he can always specify -Dtests.failfast=false. It now depends what is the default behavior we want to have. Any thoughts? Shai
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654554#comment-13654554 ] Steve Rowe commented on LUCENE-4956: bq. Yesterday I called a vote for this contribution on gene...@incubator.apache.org: [http://mail-archives.apache.org/mod_mbox/incubator-general/201305.mbox/%3c7ad4d4e3-530b-41e3-8323-da3d66a40...@apache.org%3e] This vote has passed, so we're now free to incorporate this contribution into the code base when and as we see fit. the korean analyzer that has a korean morphological analyzer and dictionaries - Key: LUCENE-4956 URL: https://issues.apache.org/jira/browse/LUCENE-4956 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Affects Versions: 4.2 Reporter: SooMyung Lee Assignee: Christian Moen Labels: newbie Attachments: kr.analyzer.4x.tar Korean language has specific characteristic. When developing search service with lucene solr in korean, there are some problems in searching and indexing. The korean analyer solved the problems with a korean morphological anlyzer. It consists of a korean morphological analyzer, dictionaries, a korean tokenizer and a korean filter. The korean anlyzer is made for lucene and solr. If you develop a search service with lucene in korean, It is the best idea to choose the korean analyzer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-4751:
-
Fix Version/s: (was: 4.4)
(was: 5.0)
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654556#comment-13654556
]
Koji Sekiguchi commented on SOLR-4751:
--
Sorry for the inconvenience.
I'll contact the reporter and see if we can fix the tests.
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4996) DocInverterPerField to log which field throws exceptions
[ https://issues.apache.org/jira/browse/LUCENE-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654557#comment-13654557 ] Robert Muir commented on LUCENE-4996: - +1. Thanks Markus. I'll take this one. DocInverterPerField to log which field throws exceptions Key: LUCENE-4996 URL: https://issues.apache.org/jira/browse/LUCENE-4996 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Markus Jelsma Priority: Minor Fix For: 5.0, 4.4 Attachments: LUCENE-4996-trunk.patch One of ours fields seems to have a problem that didn't result in an exception before. It seems one of my filters doesn't deal with posIncAttr properly but Lucene did not log which of my numerous fields was the problem. This patch includes the field name in the exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4790) When defining a core with the same name (discovery mode or not), CoreContainer should throw an error
[ https://issues.apache.org/jira/browse/SOLR-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654577#comment-13654577 ] Commit Tag Bot commented on SOLR-4790: -- [trunk commit] erick http://svn.apache.org/viewvc?view=revisionrevision=1481079 SOLR-4790, Defining a core with the same name should throw an error When defining a core with the same name (discovery mode or not), CoreContainer should throw an error Key: SOLR-4790 URL: https://issues.apache.org/jira/browse/SOLR-4790 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-4790.patch, SOLR-4790.patch When you define a core with the same name as another core (discovery mode definitely, old-style xml probably), last one wins. Which means it's very hard to track down what caused the problem. What's worse, the last-encountered core replaces the first one, leading to cores that change an unexpected index. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4996) DocInverterPerField to log which field throws exceptions
[ https://issues.apache.org/jira/browse/LUCENE-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654579#comment-13654579 ] Commit Tag Bot commented on LUCENE-4996: [trunk commit] rmuir http://svn.apache.org/viewvc?view=revisionrevision=1481080 LUCENE-4996: Include field name in all DocInverter exceptions DocInverterPerField to log which field throws exceptions Key: LUCENE-4996 URL: https://issues.apache.org/jira/browse/LUCENE-4996 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Markus Jelsma Priority: Minor Fix For: 5.0, 4.4 Attachments: LUCENE-4996-trunk.patch One of ours fields seems to have a problem that didn't result in an exception before. It seems one of my filters doesn't deal with posIncAttr properly but Lucene did not log which of my numerous fields was the problem. This patch includes the field name in the exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4996) DocInverterPerField to log which field throws exceptions
[ https://issues.apache.org/jira/browse/LUCENE-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654583#comment-13654583 ] Commit Tag Bot commented on LUCENE-4996: [branch_4x commit] rmuir http://svn.apache.org/viewvc?view=revisionrevision=1481081 LUCENE-4996: Include field name in all DocInverter exceptions DocInverterPerField to log which field throws exceptions Key: LUCENE-4996 URL: https://issues.apache.org/jira/browse/LUCENE-4996 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Markus Jelsma Priority: Minor Fix For: 5.0, 4.4 Attachments: LUCENE-4996-trunk.patch One of ours fields seems to have a problem that didn't result in an exception before. It seems one of my filters doesn't deal with posIncAttr properly but Lucene did not log which of my numerous fields was the problem. This patch includes the field name in the exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4996) DocInverterPerField to log which field throws exceptions
[ https://issues.apache.org/jira/browse/LUCENE-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4996. - Resolution: Fixed Thanks again! DocInverterPerField to log which field throws exceptions Key: LUCENE-4996 URL: https://issues.apache.org/jira/browse/LUCENE-4996 Project: Lucene - Core Issue Type: Bug Components: core/index Reporter: Markus Jelsma Priority: Minor Fix For: 5.0, 4.4 Attachments: LUCENE-4996-trunk.patch One of ours fields seems to have a problem that didn't result in an exception before. It seems one of my filters doesn't deal with posIncAttr properly but Lucene did not log which of my numerous fields was the problem. This patch includes the field name in the exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4790) When defining a core with the same name (discovery mode or not), CoreContainer should throw an error
[ https://issues.apache.org/jira/browse/SOLR-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4790: - Attachment: SOLR-4790.patch Final patch When defining a core with the same name (discovery mode or not), CoreContainer should throw an error Key: SOLR-4790 URL: https://issues.apache.org/jira/browse/SOLR-4790 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-4790.patch, SOLR-4790.patch, SOLR-4790.patch When you define a core with the same name as another core (discovery mode definitely, old-style xml probably), last one wins. Which means it's very hard to track down what caused the problem. What's worse, the last-encountered core replaces the first one, leading to cores that change an unexpected index. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654597#comment-13654597
]
Commit Tag Bot commented on SOLR-4751:
--
[lucene_solr_4_3 commit] koji
http://svn.apache.org/viewvc?view=revisionrevision=1481094
revert SOLR-4751 change
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4991) QueryParser doesnt handle synonyms correctly for chinese
[ https://issues.apache.org/jira/browse/LUCENE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654604#comment-13654604 ] Commit Tag Bot commented on LUCENE-4991: [trunk commit] rmuir http://svn.apache.org/viewvc?view=revisionrevision=1481100 LUCENE-4991: QueryParser doesnt handle synonyms correctly for chinese QueryParser doesnt handle synonyms correctly for chinese Key: LUCENE-4991 URL: https://issues.apache.org/jira/browse/LUCENE-4991 Project: Lucene - Core Issue Type: Bug Components: modules/queryparser Reporter: Robert Muir Attachments: LUCENE-4991.patch As reported multiple times on the user list: http://find.searchhub.org/document/eaf0e88a6a0d4d1f http://find.searchhub.org/document/abf28043c52b6efc http://find.searchhub.org/document/1313794632c90826 The logic here is not forming the right query structures and ignoring positionIncrementAttribute from the tokenStream. * when default operator is AND, you can see it more clearly, as synonyms are wrongly inserted as additional MUST terms: expected:+field:中 +(field:国 field:國) but was:+field:中 +field:国 +field:國 * even when default operator is OR, its still wrong, because we ignore posInc and this means coord computation is not correct (so scoring is wrong) This also screws up scoring and queries for decompounding too (because they go thru this exact situation if they add the original compound as a synonym). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4787) Join Contrib
[
https://issues.apache.org/jira/browse/SOLR-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4787:
-
Attachment: SOLR-4787.patch
Added vjoin2 and broke out several inner classes into there own class.
Join Contrib
Key: SOLR-4787
URL: https://issues.apache.org/jira/browse/SOLR-4787
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.2.1
Reporter: Joel Bernstein
Priority: Minor
Fix For: 4.2.1
Attachments: SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch
This contrib provides a place where different join implementations can be
contributed to Solr. This contrib currently includes 2 join implementations.
The initial patch was generated from the Solr 4.2.1 tag. Because of changes
in the FieldCache API this patch will only build with Solr 4.2 or above.
*PostFilterJoinQParserPlugin aka pjoin*
The pjoin provides a join implementation that filters results in one core
based on the results of a search in another core. This is similar in
functionality to the JoinQParserPlugin but the implementation differs in a
couple of important ways.
The first way is that the pjoin is designed to work with integer join keys
only. So, in order to use pjoin, integer join keys must be included in both
the to and from core.
The second difference is that the pjoin builds memory structures that are
used to quickly connect the join keys. It also uses a custom SolrCache named
join to hold intermediate DocSets which are needed to build the join memory
structures. So, the pjoin will need more memory then the JoinQParserPlugin to
perform the join.
The main advantage of the pjoin is that it can scale to join millions of keys
between cores.
Because it's a PostFilter, it only needs to join records that match the main
query.
The syntax of the pjoin is the same as the JoinQParserPlugin except that the
plugin is referenced by the string pjoin rather then join.
fq=\{!pjoin fromCore=collection2 from=id_i to=id_i\}user:customer1
The example filter query above will search the fromCore (collection2) for
user:customer1. This query will generate a list of values from the from
field that will be used to filter the main query. Only records from the main
query, where the to field is present in the from list will be included in
the results.
The solrconfig.xml in the main query core must contain the reference to the
pjoin.
queryParser name=pjoin
class=org.apache.solr.joins.PostFilterJoinQParserPlugin/
And the join contrib jars must be registed in the solrconfig.xml.
lib dir=../../../dist/ regex=solr-joins-\d.*\.jar /
The solrconfig.xml in the fromcore must have the join SolrCache configured.
cache name=join
class=solr.LRUCache
size=4096
initialSize=1024
/
*JoinValueSourceParserPlugin aka vjoin*
The second implementation is the JoinValueSourceParserPlugin aka vjoin.
This implements a ValueSource function query that can return values from a
second core based on join keys. This allows relevance data to be stored in a
separate core and then joined in the main query.
The vjoin is called using the vjoin function query. For example:
bf=vjoin(fromCore, fromKey, fromVal, toKey)
This example shows vjoin being called by the edismax boost function
parameter. This example will return the fromVal from the fromCore. The
fromKey and toKey are used to link the records from the main query to the
records in the fromCore.
As with the pjoin, both the fromKey and toKey must be integers. Also like
the pjoin, the join SolrCache is used to hold the join memory structures.
To configure the vjoin you must register the ValueSource plugin in the
solrconfig.xml as follows:
valueSourceParser name=vjoin
class=org.apache.solr.joins.JoinValueSourceParserPlugin /
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Hi, Rollback is a good feature for people who are using Solr in non SolrCloud mode. I like Jan's idea of exposing IW.commit(MapString,String commitUserData) to Solr. A quick look at this shows that this doesn't exist yet ( http://wiki.apache.org/solr/UpdateXmlMessages#A.22commit.22_and_.22optimize.22 ) Then we could probably let the user pass the commitUserData which he tagged the commit with to rollback, and perform a rollback. Basically rollbacks can only be preformed to a commit which has been explicitly tagged. I think this should solve a lot of problems regarding rollback. If this is solvable using this method I'll create the necessary JIRA's to fix it. This method should also fix this issue pointed out I think. https://issues.apache.org/jira/browse/SOLR-4733 Mark, This idea or any other approach still wouldn't support rollbacks in SolrCloud right? On Fri, May 10, 2013 at 5:21 AM, Jan Høydahl jan@cominvent.com wrote: Hi, Thanks for clarifying, I have been thinking that full RAMbuffer triggered a commit, but I now see the difference between a flush of a segment and further down the road a commit which then links all these intermediate segments with that particular commit. So ROLLBACK closes the writer but instead of persisting docs with a commit, it cleans up all uncommitted (flushed or not) doc and files. This is actually not as bad as I thought. So the main catch with ROLLBACK then is if COMMITs are done by other clients or if autoCommit or commitWithin is being used. However, after reading http://blog.mikemccandless.com/2012/03/transactional-lucene.htmlI see that it is possible to tag COMMITs with userData, so we could make the rollback actually roll back to the last explicit commit (still assuming you're the only client around) if, say AutoCommits and CommitWithins are tagged as such. So I'm OK if you guys rather want to start improve the ROLLBACK API instead of deprecating it. A client should be certain that ALL docs since last commit gets rolled back, else the rollback command must fail. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 9. mai 2013 kl. 20:49 skrev Mikhail Khludnev mkhlud...@griddynamics.com: Mark, thanks for confirming my feeling. Hence, I ask for leaving it for old-school deployments. However, it's a good thing to clearly indicate to the user that it's not implemented for tlog. What about log WARN/ERROR and/or throw an exception with explanation? On Thu, May 9, 2013 at 10:28 AM, Jack Krupansky j...@basetechnology.comwrote: This does highlight that rollback is perfectly reasonable for embedded Solr or other dedicated, single-node, well-controlled apps, even if it doesn't work for cloud. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, May 09, 2013 1:09 PM To: dev@lucene.apache.org Subject: Re: [Discussion] Discontinue the ROLLBACK command in Solr? RAMbuffer doesn't affect this stuff - if you rollback, it rolls back to the last commit point. Flushed segments are fine. - Mark On May 9, 2013, at 12:54 PM, Mikhail Khludnev mkhlud...@griddynamics.com wrote: Jan, Could you please clarify current rollback functionality to me? Let's I have autoCommit disabled, but my RAMbuffer is not huge, hence I have few flushes after previous commit. if I invoke rollback will it forget about flushed segments? On Thu, May 2, 2013 at 12:38 AM, Jan Høydahl jan@cominvent.com wrote: Hi, Many are confused about the rollback feature in Solr, since it cannot guarantee a rollback of updates from that client since last commit. In my opinion it is pretty useless to have a rollback feature you cannot rely upon - Unless, that is, you are the only client for sure, having no autoCommit, and a huge RAMbuffer. So why don't we simply deprecate the feature in 4.x and remove it from 5.0? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com --**--** - To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics --**--**- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics http://www.griddynamics.com/ mkhlud...@griddynamics.com -- Regards, Varun Thacker http://www.vthacker.in/
[jira] [Updated] (SOLR-4787) Join Contrib
[
https://issues.apache.org/jira/browse/SOLR-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4787:
-
Description:
This contrib provides a place where different join implementations can be
contributed to Solr. This contrib currently includes 3 join implementations.
The initial patch was generated from the Solr 4.2.1 tag. Because of changes in
the FieldCache API this patch will only build with Solr 4.2 or above.
*PostFilterJoinQParserPlugin aka pjoin*
The pjoin provides a join implementation that filters results in one core based
on the results of a search in another core. This is similar in functionality to
the JoinQParserPlugin but the implementation differs in a couple of important
ways.
The first way is that the pjoin is designed to work with integer join keys
only. So, in order to use pjoin, integer join keys must be included in both the
to and from core.
The second difference is that the pjoin builds memory structures that are used
to quickly connect the join keys. It also uses a custom SolrCache named join
to hold intermediate DocSets which are needed to build the join memory
structures. So, the pjoin will need more memory then the JoinQParserPlugin to
perform the join.
The main advantage of the pjoin is that it can scale to join millions of keys
between cores.
Because it's a PostFilter, it only needs to join records that match the main
query.
The syntax of the pjoin is the same as the JoinQParserPlugin except that the
plugin is referenced by the string pjoin rather then join.
fq=\{!pjoin fromCore=collection2 from=id_i to=id_i\}user:customer1
The example filter query above will search the fromCore (collection2) for
user:customer1. This query will generate a list of values from the from
field that will be used to filter the main query. Only records from the main
query, where the to field is present in the from list will be included in
the results.
The solrconfig.xml in the main query core must contain the reference to the
pjoin.
queryParser name=pjoin
class=org.apache.solr.joins.PostFilterJoinQParserPlugin/
And the join contrib jars must be registed in the solrconfig.xml.
lib dir=../../../dist/ regex=solr-joins-\d.*\.jar /
The solrconfig.xml in the fromcore must have the join SolrCache configured.
cache name=join
class=solr.LRUCache
size=4096
initialSize=1024
/
*JoinValueSourceParserPlugin aka vjoin*
The second implementation is the JoinValueSourceParserPlugin aka vjoin. This
implements a ValueSource function query that can return values from a second
core based on join keys. This allows relevance data to be stored in a separate
core and then joined in the main query.
The vjoin is called using the vjoin function query. For example:
bf=vjoin(fromCore, fromKey, fromVal, toKey)
This example shows vjoin being called by the edismax boost function
parameter. This example will return the fromVal from the fromCore. The
fromKey and toKey are used to link the records from the main query to the
records in the fromCore.
As with the pjoin, both the fromKey and toKey must be integers. Also like the
pjoin, the join SolrCache is used to hold the join memory structures.
To configure the vjoin you must register the ValueSource plugin in the
solrconfig.xml as follows:
valueSourceParser name=vjoin
class=org.apache.solr.joins.JoinValueSourceParserPlugin /
*JoinValueSourceParserPlugin2 aka vjoin2*
vjoin2 supports personalized ValueSource joins. The syntax is similar to
vjoin but adds an extra parameter so a query can be specified to join a
specific record set from the fromCore. This is designed to allow customer
specific relevance information to be added to a separate core and then joined
at query time.
Syntax:
bf=vjoin2(fromCore,fromKey,fromVal,toKey,query)
was:
This contrib provides a place where different join implementations can be
contributed to Solr. This contrib currently includes 2 join implementations.
The initial patch was generated from the Solr 4.2.1 tag. Because of changes in
the FieldCache API this patch will only build with Solr 4.2 or above.
*PostFilterJoinQParserPlugin aka pjoin*
The pjoin provides a join implementation that filters results in one core based
on the results of a search in another core. This is similar in functionality to
the JoinQParserPlugin but the implementation differs in a couple of important
ways.
The first way is that the pjoin is designed to work with integer join keys
only. So, in order to use pjoin, integer join keys must be included in both the
to and from core.
The second difference is that the pjoin builds memory structures that are used
to quickly connect the join keys. It also uses a custom SolrCache named join
to hold intermediate DocSets which are needed to build the join memory
structures. So, the pjoin will need more memory then the
[jira] [Updated] (SOLR-4787) Join Contrib
[
https://issues.apache.org/jira/browse/SOLR-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4787:
-
Description:
This contrib provides a place where different join implementations can be
contributed to Solr. This contrib currently includes 3 join implementations.
The initial patch was generated from the Solr 4.2.1 tag. Because of changes in
the FieldCache API this patch will only build with Solr 4.2 or above.
*PostFilterJoinQParserPlugin aka pjoin*
The pjoin provides a join implementation that filters results in one core based
on the results of a search in another core. This is similar in functionality to
the JoinQParserPlugin but the implementation differs in a couple of important
ways.
The first way is that the pjoin is designed to work with integer join keys
only. So, in order to use pjoin, integer join keys must be included in both the
to and from core.
The second difference is that the pjoin builds memory structures that are used
to quickly connect the join keys. It also uses a custom SolrCache named join
to hold intermediate DocSets which are needed to build the join memory
structures. So, the pjoin will need more memory then the JoinQParserPlugin to
perform the join.
The main advantage of the pjoin is that it can scale to join millions of keys
between cores.
Because it's a PostFilter, it only needs to join records that match the main
query.
The syntax of the pjoin is the same as the JoinQParserPlugin except that the
plugin is referenced by the string pjoin rather then join.
fq=\{!pjoin fromCore=collection2 from=id_i to=id_i\}user:customer1
The example filter query above will search the fromCore (collection2) for
user:customer1. This query will generate a list of values from the from
field that will be used to filter the main query. Only records from the main
query, where the to field is present in the from list will be included in
the results.
The solrconfig.xml in the main query core must contain the reference to the
pjoin.
queryParser name=pjoin
class=org.apache.solr.joins.PostFilterJoinQParserPlugin/
And the join contrib jars must be registed in the solrconfig.xml.
lib dir=../../../dist/ regex=solr-joins-\d.*\.jar /
The solrconfig.xml in the fromcore must have the join SolrCache configured.
cache name=join
class=solr.LRUCache
size=4096
initialSize=1024
/
*JoinValueSourceParserPlugin aka vjoin*
The second implementation is the JoinValueSourceParserPlugin aka vjoin. This
implements a ValueSource function query that can return values from a second
core based on join keys. This allows relevance data to be stored in a separate
core and then joined in the main query.
The vjoin is called using the vjoin function query. For example:
bf=vjoin(fromCore, fromKey, fromVal, toKey)
This example shows vjoin being called by the edismax boost function
parameter. This example will return the fromVal from the fromCore. The
fromKey and toKey are used to link the records from the main query to the
records in the fromCore.
As with the pjoin, both the fromKey and toKey must be integers. Also like the
pjoin, the join SolrCache is used to hold the join memory structures.
To configure the vjoin you must register the ValueSource plugin in the
solrconfig.xml as follows:
valueSourceParser name=vjoin
class=org.apache.solr.joins.JoinValueSourceParserPlugin /
*JoinValueSourceParserPlugin2 aka vjoin2*
vjoin2 supports personalized ValueSource joins. The syntax is similar to
vjoin but adds an extra parameter so a query can be specified to join a
specific record set from the fromCore. This is designed to allow customer
specific relevance information to be added to fromCore and then joined at query
time.
Syntax:
bf=vjoin2(fromCore,fromKey,fromVal,toKey,query)
was:
This contrib provides a place where different join implementations can be
contributed to Solr. This contrib currently includes 3 join implementations.
The initial patch was generated from the Solr 4.2.1 tag. Because of changes in
the FieldCache API this patch will only build with Solr 4.2 or above.
*PostFilterJoinQParserPlugin aka pjoin*
The pjoin provides a join implementation that filters results in one core based
on the results of a search in another core. This is similar in functionality to
the JoinQParserPlugin but the implementation differs in a couple of important
ways.
The first way is that the pjoin is designed to work with integer join keys
only. So, in order to use pjoin, integer join keys must be included in both the
to and from core.
The second difference is that the pjoin builds memory structures that are used
to quickly connect the join keys. It also uses a custom SolrCache named join
to hold intermediate DocSets which are needed to build the join memory
structures. So, the pjoin will need more memory then the
[jira] [Commented] (SOLR-4790) When defining a core with the same name (discovery mode or not), CoreContainer should throw an error
[ https://issues.apache.org/jira/browse/SOLR-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654618#comment-13654618 ] Commit Tag Bot commented on SOLR-4790: -- [branch_4x commit] erick http://svn.apache.org/viewvc?view=revisionrevision=148 SOLR-4790, Defining a core with the same name should throw an error When defining a core with the same name (discovery mode or not), CoreContainer should throw an error Key: SOLR-4790 URL: https://issues.apache.org/jira/browse/SOLR-4790 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-4790.patch, SOLR-4790.patch, SOLR-4790.patch When you define a core with the same name as another core (discovery mode definitely, old-style xml probably), last one wins. Which means it's very hard to track down what caused the problem. What's worse, the last-encountered core replaces the first one, leading to cores that change an unexpected index. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4790) When defining a core with the same name (discovery mode or not), CoreContainer should throw an error
[ https://issues.apache.org/jira/browse/SOLR-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-4790. -- Resolution: Fixed Fix Version/s: 4.4 5.0 When defining a core with the same name (discovery mode or not), CoreContainer should throw an error Key: SOLR-4790 URL: https://issues.apache.org/jira/browse/SOLR-4790 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Fix For: 5.0, 4.4 Attachments: SOLR-4790.patch, SOLR-4790.patch, SOLR-4790.patch When you define a core with the same name as another core (discovery mode definitely, old-style xml probably), last one wins. Which means it's very hard to track down what caused the problem. What's worse, the last-encountered core replaces the first one, leading to cores that change an unexpected index. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
There's an issue open: https://issues.apache.org/jira/browse/SOLR-2701 On Fri, May 10, 2013 at 10:14 AM, Varun Thacker varunthacker1...@gmail.comwrote: Hi, Rollback is a good feature for people who are using Solr in non SolrCloud mode. I like Jan's idea of exposing IW.commit(MapString,String commitUserData) to Solr. A quick look at this shows that this doesn't exist yet ( http://wiki.apache.org/solr/UpdateXmlMessages#A.22commit.22_and_.22optimize.22 ) Then we could probably let the user pass the commitUserData which he tagged the commit with to rollback, and perform a rollback. Basically rollbacks can only be preformed to a commit which has been explicitly tagged. I think this should solve a lot of problems regarding rollback. If this is solvable using this method I'll create the necessary JIRA's to fix it. This method should also fix this issue pointed out I think. https://issues.apache.org/jira/browse/SOLR-4733 Mark, This idea or any other approach still wouldn't support rollbacks in SolrCloud right? On Fri, May 10, 2013 at 5:21 AM, Jan Høydahl jan@cominvent.comwrote: Hi, Thanks for clarifying, I have been thinking that full RAMbuffer triggered a commit, but I now see the difference between a flush of a segment and further down the road a commit which then links all these intermediate segments with that particular commit. So ROLLBACK closes the writer but instead of persisting docs with a commit, it cleans up all uncommitted (flushed or not) doc and files. This is actually not as bad as I thought. So the main catch with ROLLBACK then is if COMMITs are done by other clients or if autoCommit or commitWithin is being used. However, after reading http://blog.mikemccandless.com/2012/03/transactional-lucene.htmlI see that it is possible to tag COMMITs with userData, so we could make the rollback actually roll back to the last explicit commit (still assuming you're the only client around) if, say AutoCommits and CommitWithins are tagged as such. So I'm OK if you guys rather want to start improve the ROLLBACK API instead of deprecating it. A client should be certain that ALL docs since last commit gets rolled back, else the rollback command must fail. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 9. mai 2013 kl. 20:49 skrev Mikhail Khludnev mkhlud...@griddynamics.com : Mark, thanks for confirming my feeling. Hence, I ask for leaving it for old-school deployments. However, it's a good thing to clearly indicate to the user that it's not implemented for tlog. What about log WARN/ERROR and/or throw an exception with explanation? On Thu, May 9, 2013 at 10:28 AM, Jack Krupansky j...@basetechnology.comwrote: This does highlight that rollback is perfectly reasonable for embedded Solr or other dedicated, single-node, well-controlled apps, even if it doesn't work for cloud. -- Jack Krupansky -Original Message- From: Mark Miller Sent: Thursday, May 09, 2013 1:09 PM To: dev@lucene.apache.org Subject: Re: [Discussion] Discontinue the ROLLBACK command in Solr? RAMbuffer doesn't affect this stuff - if you rollback, it rolls back to the last commit point. Flushed segments are fine. - Mark On May 9, 2013, at 12:54 PM, Mikhail Khludnev mkhlud...@griddynamics.com wrote: Jan, Could you please clarify current rollback functionality to me? Let's I have autoCommit disabled, but my RAMbuffer is not huge, hence I have few flushes after previous commit. if I invoke rollback will it forget about flushed segments? On Thu, May 2, 2013 at 12:38 AM, Jan Høydahl jan@cominvent.com wrote: Hi, Many are confused about the rollback feature in Solr, since it cannot guarantee a rollback of updates from that client since last commit. In my opinion it is pretty useless to have a rollback feature you cannot rely upon - Unless, that is, you are the only client for sure, having no autoCommit, and a huge RAMbuffer. So why don't we simply deprecate the feature in 4.x and remove it from 5.0? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com --**--** - To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics --**--** - To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org --**--** - To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org --
[jira] [Created] (SOLR-4808) Persist and use replication factor at Collection and Shard level
Anshum Gupta created SOLR-4808: -- Summary: Persist and use replication factor at Collection and Shard level Key: SOLR-4808 URL: https://issues.apache.org/jira/browse/SOLR-4808 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Anshum Gupta The replication factor for a collection as of now is not persisted and used while adding replicas. We should save the replication factor at collection factor as well as shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4991) QueryParser doesnt handle synonyms correctly for chinese
[ https://issues.apache.org/jira/browse/LUCENE-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13654647#comment-13654647 ] Commit Tag Bot commented on LUCENE-4991: [branch_4x commit] rmuir http://svn.apache.org/viewvc?view=revisionrevision=1481116 LUCENE-4991: QueryParser doesnt handle synonyms correctly for chinese QueryParser doesnt handle synonyms correctly for chinese Key: LUCENE-4991 URL: https://issues.apache.org/jira/browse/LUCENE-4991 Project: Lucene - Core Issue Type: Bug Components: modules/queryparser Reporter: Robert Muir Attachments: LUCENE-4991.patch As reported multiple times on the user list: http://find.searchhub.org/document/eaf0e88a6a0d4d1f http://find.searchhub.org/document/abf28043c52b6efc http://find.searchhub.org/document/1313794632c90826 The logic here is not forming the right query structures and ignoring positionIncrementAttribute from the tokenStream. * when default operator is AND, you can see it more clearly, as synonyms are wrongly inserted as additional MUST terms: expected:+field:中 +(field:国 field:國) but was:+field:中 +field:国 +field:國 * even when default operator is OR, its still wrong, because we ignore posInc and this means coord computation is not correct (so scoring is wrong) This also screws up scoring and queries for decompounding too (because they go thru this exact situation if they add the original compound as a synonym). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
