[jira] [Resolved] (LUCENE-5407) Deadlock? while indexing in cascaded threads
[ https://issues.apache.org/jira/browse/LUCENE-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer resolved LUCENE-5407. - Resolution: Not A Problem Assignee: Simon Willnauer closing... this is not what the IW was designed for. Deadlock? while indexing in cascaded threads Key: LUCENE-5407 URL: https://issues.apache.org/jira/browse/LUCENE-5407 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: Windows 7 64 bits, JRE 1.7.0_25 64 bits Reporter: Luis Filipe Nassif Assignee: Simon Willnauer Attachments: Test.java, thread_dump.txt Apparently I found a deadlock problem with IndexWriter in a cascaded thread design to add documents (I am working on an application integrating Tika, which has the capability to add embedded documents to the index as independent documents as they are found). The attached code illustrates the problem. Sometimes it stops processing, at least one of the threads remains in WAITING state. It must be executed no more than 5 times in my environment to trigger the problem. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5407) Deadlock? while indexing in cascaded threads
[ https://issues.apache.org/jira/browse/LUCENE-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878397#comment-13878397 ] Simon Willnauer commented on LUCENE-5407: - There is no way this would work here. Your first thread enters the index writer and gets a threadstate and then once it pulls the fields reader you enter the indexwriter again to add a sub-document. This sub-document IW#addDocument call tries to get a thread-state as well but since there are only 8 ThreadStates by default you run into a deadlock since for the parent-doc thread to make progress the sub-documents thread must return from IW#addDocument but it can't since it waits for another thread to release one of the ThreadStates. So yes that is a deadlock situation but I really don't see any way this could work. I guess further this approach is not what I recommend you do anyways. If you want to index those documents in a stream then I guess a producer - queue - consumer approach might be best suited. Deadlock? while indexing in cascaded threads Key: LUCENE-5407 URL: https://issues.apache.org/jira/browse/LUCENE-5407 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: Windows 7 64 bits, JRE 1.7.0_25 64 bits Reporter: Luis Filipe Nassif Attachments: Test.java, thread_dump.txt Apparently I found a deadlock problem with IndexWriter in a cascaded thread design to add documents (I am working on an application integrating Tika, which has the capability to add embedded documents to the index as independent documents as they are found). The attached code illustrates the problem. Sometimes it stops processing, at least one of the threads remains in WAITING state. It must be executed no more than 5 times in my environment to trigger the problem. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878403#comment-13878403
]
ASF subversion and git services commented on SOLR-5476:
---
Commit 1560279 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1560279 ]
SOLR-5476 hardened a bit
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878405#comment-13878405
]
ASF subversion and git services commented on SOLR-5476:
---
Commit 1560280 from [~noble.paul] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1560280 ]
SOLR-5476 hardened a bit
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878407#comment-13878407
]
Noble Paul commented on SOLR-5476:
--
[~markrmil...@gmail.com] What is the sure shot way for
Overseer/OverseerCollectionProcessor to quit and somebody else take its place?
The failures are due to the leader not giving up
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878453#comment-13878453
]
Shalin Shekhar Mangar commented on SOLR-5476:
-
Perhaps you can create your own instance of overseer and force election just
like OverseerTest does with OverseerRestarter?
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
JDK 8 Build 124 JDK 7 Update 60 build 03 are available on java.net
Hi Uwe/Dawid, JDK 8 Build b124 Early Access Build is now available for download http://jdk8.java.net/download.html test. JDK 7u60 b03 Early Access Build is also available for download https://jdk7.java.net/download.html test. See you at FOSDEM next week. Thanks for your support, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878534#comment-13878534
]
ASF subversion and git services commented on SOLR-5476:
---
Commit 1560314 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1560314 ]
SOLR-5476 ignored till there is a reliable way to restart Overseer
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5476) Overseer Role for nodes
[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878537#comment-13878537
]
ASF subversion and git services commented on SOLR-5476:
---
Commit 1560315 from [~noble.paul] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1560315 ]
SOLR-5476 needs a reliable way to restart Overseer
Overseer Role for nodes
---
Key: SOLR-5476
URL: https://issues.apache.org/jira/browse/SOLR-5476
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0, 4.7
Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch,
SOLR-5476.patch, SOLR-5476.patch
In a very large cluster the Overseer is likely to be overloaded.If the same
node is a serving a few other shards it can lead to OverSeer getting slowed
down due to GC pauses , or simply too much of work . If the cluster is
really large , it is possible to dedicate high end h/w for OverSeers
It works as a new collection admin command
command=addrolerole=overseernode=192.168.1.5:8983_solr
This results in the creation of a entry in the /roles.json in ZK which would
look like the following
{code:javascript}
{
overseer : [192.168.1.5:8983_solr]
}
{code}
If a node is designated for overseer it gets preference over others when
overseer election takes place. If no designated servers are available another
random node would become the Overseer.
Later on, if one of the designated nodes are brought up ,it would take over
the Overseer role from the current Overseer to become the Overseer of the
system
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5651) Make labels clickable and the output wrapped in UI
[ https://issues.apache.org/jira/browse/SOLR-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5651: Fix Version/s: (was: 4.6.1) 4.7 5.0 Make labels clickable and the output wrapped in UI -- Key: SOLR-5651 URL: https://issues.apache.org/jira/browse/SOLR-5651 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.6 Reporter: Artem Lukanin Fix For: 5.0, 4.7 Attachments: SOLR-5651_clickable_labels.patch, SOLR-5651_clickable_labels.patch Now it is practically impossible to tick off check boxes in the UI, because the label text is wrapped in a fancy A tag without HREF. Also it is very hard to read the output on the Query menu when debugQuery=true. It is impossible to scroll the window to the right. It would be better if the text in the PRE tag was wrapped. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5651) Make labels clickable and the output wrapped in UI
[ https://issues.apache.org/jira/browse/SOLR-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5651: Component/s: web gui Make labels clickable and the output wrapped in UI -- Key: SOLR-5651 URL: https://issues.apache.org/jira/browse/SOLR-5651 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.6 Reporter: Artem Lukanin Fix For: 5.0, 4.7 Attachments: SOLR-5651_clickable_labels.patch, SOLR-5651_clickable_labels.patch Now it is practically impossible to tick off check boxes in the UI, because the label text is wrapped in a fancy A tag without HREF. Also it is very hard to read the output on the Query menu when debugQuery=true. It is impossible to scroll the window to the right. It would be better if the text in the PRE tag was wrapped. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC2
+1 SUCCESS! [0:29:25.421656] -- Ran from a local cached copy of the files :) -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 20. jan. 2014 kl. 03:29 skrev Mark Miller markrmil...@gmail.com: Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1559610/ Here is my +1. SUCCESS! [0:51:51.964657] -- - Mark
[jira] [Commented] (LUCENE-5377) Lucene 4.6 cause mixed version segments info file(.si) wrong
[
https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878572#comment-13878572
]
Michael McCandless commented on LUCENE-5377:
Indeed, something is wrong here.
If I fix DirectoryTaxonomyWriter to use IW.addIndexes(IR[]) instead of
IW.addIndexes(Directory[]) then the test passes. The bug is due to this code
in IndexWriter.addIndces(Dir[]):
{noformat}
TrackingDirectoryWrapper trackingDir = new
TrackingDirectoryWrapper(directory);
try {
newInfo.getCodec().segmentInfoFormat().getSegmentInfoWriter().write(trackingDir,
newInfo, fis, context);
} catch (UnsupportedOperationException uoe) {
// OK: 3x codec cannot write a new SI file;
// SegmentInfos will write this on commit
}
{noformat}
The problem is ... this logic is wrong: the segment was written with
Lucene40SegmentInfoFormat, which works in 4.5.x but in 4.6.x we upgraded this
to Lucene46SIFormat...
Lucene 4.6 cause mixed version segments info file(.si) wrong
Key: LUCENE-5377
URL: https://issues.apache.org/jira/browse/LUCENE-5377
Project: Lucene - Core
Issue Type: Bug
Components: core/index, modules/facet
Affects Versions: 4.6
Environment: windows/linux
Reporter: Littlestar
Attachments: TestCore_45.java, TestCore_46.java
my old facet index create by Lucene version=4.2
use indexChecker ok.
now I upgrade to Lucene 4.6 and put some new records to index.
then reopen index, some files in indexdir missing
no .si files.
I debug into it, new version format of segments.gen(segments_N) record bad
segments info.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5407) Deadlock? while indexing in cascaded threads
[ https://issues.apache.org/jira/browse/LUCENE-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878593#comment-13878593 ] Luis Filipe Nassif commented on LUCENE-5407: Thank you for comment. Although there are less than 8 threads in example, I agree the general case will not work. Deadlock? while indexing in cascaded threads Key: LUCENE-5407 URL: https://issues.apache.org/jira/browse/LUCENE-5407 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: Windows 7 64 bits, JRE 1.7.0_25 64 bits Reporter: Luis Filipe Nassif Assignee: Simon Willnauer Attachments: Test.java, thread_dump.txt Apparently I found a deadlock problem with IndexWriter in a cascaded thread design to add documents (I am working on an application integrating Tika, which has the capability to add embedded documents to the index as independent documents as they are found). The attached code illustrates the problem. Sometimes it stops processing, at least one of the threads remains in WAITING state. It must be executed no more than 5 times in my environment to trigger the problem. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) Lucene 4.6 cause mixed version segments info file(.si) wrong
[
https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878604#comment-13878604
]
Shai Erera commented on LUCENE-5377:
Isn't it then a problem of anyone that will try to addIndexes a pre-4.6 index
to a 4.6+?
I looked at TestBackCompat.addOldIndexes - it doesn't do anything with the
added index to verify it's OK. I added
{{DirectoryReader.open(targetDir).close();}} to the test after {{w.close()}},
so at least we verify the index can be opened, but the test doesn't fail, not
sure why. The newest oldNames is 4.2 - shouldn't a 4.5 have been created when
we released 4.6, since we changed the index format? But then a 4.0/4.2 index
should equally fail to be added to a 4.6, right? So maybe this doesn't explain
the failure to reproduce this error...
Lucene 4.6 cause mixed version segments info file(.si) wrong
Key: LUCENE-5377
URL: https://issues.apache.org/jira/browse/LUCENE-5377
Project: Lucene - Core
Issue Type: Bug
Components: core/index, modules/facet
Affects Versions: 4.6
Environment: windows/linux
Reporter: Littlestar
Attachments: TestCore_45.java, TestCore_46.java
my old facet index create by Lucene version=4.2
use indexChecker ok.
now I upgrade to Lucene 4.6 and put some new records to index.
then reopen index, some files in indexdir missing
no .si files.
I debug into it, new version format of segments.gen(segments_N) record bad
segments info.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3565) StandardQueryParser generates incorrect query for groups containing one term if using default operator AND
[
https://issues.apache.org/jira/browse/LUCENE-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878608#comment-13878608
]
Trejkaz commented on LUCENE-3565:
-
The expectation in the test case aside, what Lucene was actually returning was
+text:a +text:b, ignoring the OR entirely.
This seems to have been fixed somewhere between 3.6.0 and 3.6.2, though.
StandardQueryParser generates incorrect query for groups containing one term
if using default operator AND
--
Key: LUCENE-3565
URL: https://issues.apache.org/jira/browse/LUCENE-3565
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 3.4
Reporter: Trejkaz
Labels: queryparser
The following test demonstrates a bug in StandardQueryParser when
DEFAULT_OPERATOR is set to AND:
{code}
@Test
public void testDefaultOperatorSingleGrouped() throws Exception
{
StandardQueryParser parser = new StandardQueryParser();
parser.getQueryConfigHandler().set(StandardQueryConfigHandler.ConfigurationKeys.DEFAULT_OPERATOR,
StandardQueryConfigHandler.Operator.AND);
BooleanQuery expectedQuery = new BooleanQuery();
BooleanQuery innerQuery1 = new BooleanQuery();
innerQuery1.add(new TermQuery(new Term(text, a)),
BooleanClause.Occur.MUST);
expectedQuery.add(innerQuery1, BooleanClause.Occur.SHOULD);
BooleanQuery innerQuery2 = new BooleanQuery();
innerQuery2.add(new TermQuery(new Term(text, b)),
BooleanClause.Occur.MUST);
expectedQuery.add(innerQuery2, BooleanClause.Occur.SHOULD);
Query actualQuery = parser.parse((a) OR (b), text);
assertEquals(Wrong query was generated, expectedQuery, actualQuery);
}
{code}
BooleanSingleChildOptimizationQueryNodeProcessor appears to be responsible
because if I remove it, the correct query is generated (however, doing so
breaks a number of other tests of our own.)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3565) StandardQueryParser generates incorrect query for groups containing one term if using default operator AND
[
https://issues.apache.org/jira/browse/LUCENE-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878615#comment-13878615
]
Trejkaz commented on LUCENE-3565:
-
And actually, if you read my original comment from 2011, I accepted that both
being SHOULD would have been a valid result too. But that is definitely not
what it was generating. :)
StandardQueryParser generates incorrect query for groups containing one term
if using default operator AND
--
Key: LUCENE-3565
URL: https://issues.apache.org/jira/browse/LUCENE-3565
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 3.4
Reporter: Trejkaz
Labels: queryparser
The following test demonstrates a bug in StandardQueryParser when
DEFAULT_OPERATOR is set to AND:
{code}
@Test
public void testDefaultOperatorSingleGrouped() throws Exception
{
StandardQueryParser parser = new StandardQueryParser();
parser.getQueryConfigHandler().set(StandardQueryConfigHandler.ConfigurationKeys.DEFAULT_OPERATOR,
StandardQueryConfigHandler.Operator.AND);
BooleanQuery expectedQuery = new BooleanQuery();
BooleanQuery innerQuery1 = new BooleanQuery();
innerQuery1.add(new TermQuery(new Term(text, a)),
BooleanClause.Occur.MUST);
expectedQuery.add(innerQuery1, BooleanClause.Occur.SHOULD);
BooleanQuery innerQuery2 = new BooleanQuery();
innerQuery2.add(new TermQuery(new Term(text, b)),
BooleanClause.Occur.MUST);
expectedQuery.add(innerQuery2, BooleanClause.Occur.SHOULD);
Query actualQuery = parser.parse((a) OR (b), text);
assertEquals(Wrong query was generated, expectedQuery, actualQuery);
}
{code}
BooleanSingleChildOptimizationQueryNodeProcessor appears to be responsible
because if I remove it, the correct query is generated (however, doing so
breaks a number of other tests of our own.)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) Lucene 4.6 cause mixed version segments info file(.si) wrong
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878686#comment-13878686 ] Robert Muir commented on LUCENE-5377: - First of all, some test should fail. IndexWriter.addIndexes(Dir) is so dangerous... To fix the bug, i think we have to support write logic in the old .si writer? And only allow the UOE if its really 3.x codec... Long term this is bogus. We should either remove IndexWriter.addIndexes(Dir) or change things so it doesnt need to write .si at all here (e.g. put partial filenames in the .si that don't include segment prefix) Lucene 4.6 cause mixed version segments info file(.si) wrong Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index, modules/facet Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Attachments: TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878687#comment-13878687 ] Michael McCandless commented on LUCENE-3069: Note that all the commit messages at the end of this issue (generated by Jira's FishEye plugin I think) incorrectly state that Han Lee committed changes here. This is due to an issue in FishEye with username collision ... Han Jiang's (who really committed here) apache username is han, but in Jira that user name belongs to Han Lee, which leads to this mis-labeling. Here's the INFRA issue: https://issues.apache.org/jira/browse/INFRA-3243 but it's currently WONTFIX unfortunately ... Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5598) LanguageIdentifierUpdateProcessor ignores all but the first value of multiValued string fields
[
https://issues.apache.org/jira/browse/SOLR-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5598:
---
Attachment: SOLR-5598.patch
Added content logging in case of non-string value
Added test for multivalue field with 1st value as empty string
Added test for multivalue field with values in 2languages (most en). resolved
as en.
LanguageIdentifierUpdateProcessor ignores all but the first value of
multiValued string fields
--
Key: SOLR-5598
URL: https://issues.apache.org/jira/browse/SOLR-5598
Project: Solr
Issue Type: Bug
Components: contrib - LangId
Affects Versions: 4.5.1
Reporter: Andreas Hubold
Fix For: 4.7
Attachments: SOLR-5598.patch, SOLR-5598.patch
The LanguageIdentifierUpdateProcessor just uses the first value of the
multiValued field to detect the language.
Method {{concatFields}} calls {{doc.getFieldValue(fieldName)}} but should
instead iterate over {{doc.getFieldValues(fieldName)}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) Lucene 4.6 cause mixed version segments info file(.si) wrong
[
https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878701#comment-13878701
]
Shai Erera commented on LUCENE-5377:
bq. First of all, some test should fail.
I modified TestBackCompatibility.testAddIndexes to do this:
{code}
boolean orig = OLD_FORMAT_IMPERSONATION_IS_ACTIVE;
OLD_FORMAT_IMPERSONATION_IS_ACTIVE = false;
// test code goes here
OLD_FORMAT_IMPERSONATION_IS_ACTIVE = orig;
{code}
And now it fails, because writing with old Codecs is not supported. Maybe it
cannot be done like that for 4x because we need to support 3x indexes, but I
haven't tried (because in 4x we catch and ignore the UOE, so I don't know yet
how it will affect the test).
bq. or change things so it doesnt need to write .si at all here (e.g. put
partial filenames in the .si that don't include segment prefix)
That's a good idea - if we strip the segment name from the files .si records
(which is redundant anyway!), we won't need to rewrite .si. I believe though
that we should fix this in 4.6.1?
Lucene 4.6 cause mixed version segments info file(.si) wrong
Key: LUCENE-5377
URL: https://issues.apache.org/jira/browse/LUCENE-5377
Project: Lucene - Core
Issue Type: Bug
Components: core/index, modules/facet
Affects Versions: 4.6
Environment: windows/linux
Reporter: Littlestar
Attachments: TestCore_45.java, TestCore_46.java
my old facet index create by Lucene version=4.2
use indexChecker ok.
now I upgrade to Lucene 4.6 and put some new records to index.
then reopen index, some files in indexdir missing
no .si files.
I debug into it, new version format of segments.gen(segments_N) record bad
segments info.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5377) Lucene 4.6 cause mixed version segments info file(.si) wrong
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5377: Component/s: (was: modules/facet) Lucene 4.6 cause mixed version segments info file(.si) wrong Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Attachments: TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5377: --- Summary: IW.addIndexes(Dir[]) causes silent index corruption (was: Lucene 4.6 cause mixed version segments info file(.si) wrong) IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Attachments: TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC2
I think we should respin after we fix https://issues.apache.org/jira/browse/LUCENE-5377 ... Mike McCandless http://blog.mikemccandless.com On Wed, Jan 22, 2014 at 6:42 AM, Jan Høydahl jan@cominvent.com wrote: +1 SUCCESS! [0:29:25.421656] -- Ran from a local cached copy of the files :) -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 20. jan. 2014 kl. 03:29 skrev Mark Miller markrmil...@gmail.com: Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1559610/ Here is my +1. SUCCESS! [0:51:51.964657] -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[
https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878709#comment-13878709
]
Robert Muir commented on LUCENE-5377:
-
{quote}
And now it fails, because writing with old Codecs is not supported. Maybe it
cannot be done like that for 4x because we need to support 3x indexes, but I
haven't tried (because in 4x we catch and ignore the UOE, so I don't know yet
how it will affect the test).
{quote}
Oh, thanks for investigating. Now i understand how it got thru the tests.
Impersonation masked the bug
{quote}
That's a good idea - if we strip the segment name from the files .si records
(which is redundant anyway!), we won't need to rewrite .si. I believe though
that we should fix this in 4.6.1?
{quote}
But thats the long-term fix. For the short term i think we should just allow
the old .si format to be written. Very simple, very clean and conservative
solution, just not elegant at all.
Yes, this is a corruption issue. I really think we should respin 4.6.1 for this.
IW.addIndexes(Dir[]) causes silent index corruption
---
Key: LUCENE-5377
URL: https://issues.apache.org/jira/browse/LUCENE-5377
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.6
Environment: windows/linux
Reporter: Littlestar
Attachments: TestCore_45.java, TestCore_46.java
my old facet index create by Lucene version=4.2
use indexChecker ok.
now I upgrade to Lucene 4.6 and put some new records to index.
then reopen index, some files in indexdir missing
no .si files.
I debug into it, new version format of segments.gen(segments_N) record bad
segments info.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878719#comment-13878719 ] Shai Erera commented on LUCENE-5377: bq. For the short term i think we should just allow the old .si format to be written. You mean to temporarily restore Lucene40SIWriter? That will also fix it :) IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Attachments: TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878720#comment-13878720 ] Robert Muir commented on LUCENE-5377: - Exactly. I think this (and fixing the test bugs here), is all we should do for 4.6.1 here, lets do the segment-stripping separately? IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Attachments: TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878726#comment-13878726 ] Shai Erera commented on LUCENE-5377: OK let's fix it separately. A new Codec ... just the thought ... IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Attachments: TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878725#comment-13878725 ] Michael McCandless commented on LUCENE-5377: bq. I think this (and fixing the test bugs here), is all we should do for 4.6.1 here, lets do the segment-stripping separately? +1 IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Attachments: TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878732#comment-13878732 ] Robert Muir commented on LUCENE-5377: - the test infra is really screwed up here! There might be more hidden bugs! IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Attachments: TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reassigned LUCENE-5377: --- Assignee: Robert Muir IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Attachments: TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-5409) ToParentBlockJoinCollector.getTopGroups returns empty Groups
[ https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-5409: -- Assignee: Michael McCandless ToParentBlockJoinCollector.getTopGroups returns empty Groups Key: LUCENE-5409 URL: https://issues.apache.org/jira/browse/LUCENE-5409 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.6 Environment: Ubuntu 12.04 Reporter: Peng Cheng Assignee: Michael McCandless Priority: Critical Fix For: 4.7 Original Estimate: 168h Remaining Estimate: 168h A bug is observed to cause unstable results returned by the getTopGroups function of class ToParentBlockJoinCollector. In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the lookup will largely fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). An easy fix would be to rewrite the original BlockJoinQuery before invoking getTopGroups method. However, the computational cost of this is not optimal. A better but slightly more complex solution would be to save unrewrited Queries into the lookup table. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5594) Enable using extended field types with prefix queries for non-default encoded strings
[ https://issues.apache.org/jira/browse/SOLR-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878743#comment-13878743 ] Anshum Gupta commented on SOLR-5594: Thanks for that info Steve. I was able to set the svn property (just that I was trying to accomplish that through my IDE, which didn't work). Also, I'll use those ANT_OPTS to have stuff working for now. Enable using extended field types with prefix queries for non-default encoded strings - Key: SOLR-5594 URL: https://issues.apache.org/jira/browse/SOLR-5594 Project: Solr Issue Type: Improvement Components: query parsers, Schema and Analysis Affects Versions: 4.6 Reporter: Anshum Gupta Assignee: Anshum Gupta Priority: Minor Attachments: SOLR-5594-branch_4x.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch Enable users to be able to use prefix query with custom field types with non-default encoding/decoding for queries more easily. e.g. having a custom field work with base64 encoded query strings. Currently, the workaround for it is to have the override at getRewriteMethod level. Perhaps having the prefixQuery also use the calling FieldType's readableToIndexed method would work better. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5377: Attachment: LUCENE-5377.patch Here is a patch. Somehow, this impersonation flag dangerously got turned on by default. Thats the root cause of the test issue. Some tests that explicitly create old codecs for writing will fail with the patch. We have to fix them to use the boolean. IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Attachments: LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5409) ToParentBlockJoinCollector.getTopGroups returns empty Groups
[ https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878749#comment-13878749 ] Michael McCandless commented on LUCENE-5409: Hi Peng, this is a good catch! Probably we could key on the .origChildQuery since we already carry that one along. Do you have a test case showing the issue? ToParentBlockJoinCollector.getTopGroups returns empty Groups Key: LUCENE-5409 URL: https://issues.apache.org/jira/browse/LUCENE-5409 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.6 Environment: Ubuntu 12.04 Reporter: Peng Cheng Assignee: Michael McCandless Priority: Critical Fix For: 4.7 Original Estimate: 168h Remaining Estimate: 168h A bug is observed to cause unstable results returned by the getTopGroups function of class ToParentBlockJoinCollector. In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the lookup will largely fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). An easy fix would be to rewrite the original BlockJoinQuery before invoking getTopGroups method. However, the computational cost of this is not optimal. A better but slightly more complex solution would be to save unrewrited Queries into the lookup table. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878764#comment-13878764 ] Shai Erera commented on LUCENE-5377: I guess I messed this up when working on LUCENE-5196, turning impersonation to true by default. Sorry about that, hope it won't impact a lot of tests. IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Attachments: LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878765#comment-13878765 ] Mark Miller commented on LUCENE-3069: - I think it's actually two different things - our commit messages are generated by a script that subscribes to svnpubsub, and it does some look ups to figure out the right user name. The fisheye stuff is what you see if you look at the source tab I think. So it might be easier to fix, since I think it's in our control (INFRA's anyway). https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svngit2jira/ Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5377: Attachment: LUCENE-5377.patch I fixed all these tests here. So this patch fixes the disease (in the test infra), and fixes 4.0 SIFormat to be able to write .si just for this purpose. The bug does not really impact trunk, as it didnt have the dangerous 'catch UOE', on trunk the bug is the user would get an actual UOE. But this is fixed, as now the SIFormat can write. I think this patch is ready: for the backport we have to ensure we only hide that UOE if its really Lucene3x, so an instanceof is really needed there. IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878773#comment-13878773 ] Michael McCandless commented on LUCENE-5377: +1, looks good. IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated LUCENE-5377: Fix Version/s: 4.6.1 4.7 5.0 IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878778#comment-13878778 ] Shai Erera commented on LUCENE-5377: +1, looks good! IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878790#comment-13878790 ] Robert Muir commented on LUCENE-5377: - I opened a followup issue (LUCENE-5412) for the correct fix. But this one is too dangerous IMO for a bugfix release. IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5412) SI.files should strip segment names
Robert Muir created LUCENE-5412: --- Summary: SI.files should strip segment names Key: LUCENE-5412 URL: https://issues.apache.org/jira/browse/LUCENE-5412 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Followup from LUCENE-5377: the root cause of all the hair there is because SI.files (set of files used by the segment), must be rewritten in addIndexes because its invalidated by the change of segment name. alternatively we could just not store this stuff, and strip the segment names. This is how CFS deals with this issue already. I think we can do this in a backwards compatible way too: for old codecs, the readers could be changed to simply strip internally (e.g. ignore the extra information they wrote) ? -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5412) SI.files should strip segment names
[ https://issues.apache.org/jira/browse/LUCENE-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878798#comment-13878798 ] Robert Muir commented on LUCENE-5412: - Exactly, something like that: I dont think we should change our high-level API? SI.files should return the set of actual filenames as it does now. This would just be a change to the codec API, to e.g. strip the stuff we pass to the SI Writer or whatever. And the old codecs would strip what they read (as they wrote the unnecessary additional stuff). And we remove the call to SIWriter in addIndexes :) SI.files should strip segment names --- Key: LUCENE-5412 URL: https://issues.apache.org/jira/browse/LUCENE-5412 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Followup from LUCENE-5377: the root cause of all the hair there is because SI.files (set of files used by the segment), must be rewritten in addIndexes because its invalidated by the change of segment name. alternatively we could just not store this stuff, and strip the segment names. This is how CFS deals with this issue already. I think we can do this in a backwards compatible way too: for old codecs, the readers could be changed to simply strip internally (e.g. ignore the extra information they wrote) ? -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5412) SI.files should strip segment names
[ https://issues.apache.org/jira/browse/LUCENE-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878796#comment-13878796 ] Shai Erera commented on LUCENE-5412: Could we change SegmentInfo.setFiles() to strip the segment name maybe? Just thinking of fewer places in the code to touch. SI.files should strip segment names --- Key: LUCENE-5412 URL: https://issues.apache.org/jira/browse/LUCENE-5412 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Followup from LUCENE-5377: the root cause of all the hair there is because SI.files (set of files used by the segment), must be rewritten in addIndexes because its invalidated by the change of segment name. alternatively we could just not store this stuff, and strip the segment names. This is how CFS deals with this issue already. I think we can do this in a backwards compatible way too: for old codecs, the readers could be changed to simply strip internally (e.g. ignore the extra information they wrote) ? -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878800#comment-13878800 ] ASF subversion and git services commented on LUCENE-5377: - Commit 1560401 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1560401 ] LUCENE-5377: IW.addIndexes(Dir[]) causes silent index corruption IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: JDK 8 Build 124 JDK 7 Update 60 build 03 are available on java.net
Hi Rory, I installed both versions. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Rory O'Donnell Oracle, Dublin Ireland [mailto:rory.odonn...@oracle.com] Sent: Wednesday, January 22, 2014 12:08 PM To: Uwe Schindler; Dawid Weiss Cc: dev@lucene.apache.org; Dalibor Topic; Cecilia Borg; Balchandra Vaidya Subject: JDK 8 Build 124 JDK 7 Update 60 build 03 are available on java.net Hi Uwe/Dawid, JDK 8 Build b124 Early Access Build is now available for download http://jdk8.java.net/download.html test. JDK 7u60 b03 Early Access Build is also available for download https://jdk7.java.net/download.html test. See you at FOSDEM next week. Thanks for your support, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878805#comment-13878805 ] ASF subversion and git services commented on LUCENE-5377: - Commit 1560405 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1560405 ] LUCENE-5377: remove dead code IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878808#comment-13878808 ] Robert Muir commented on LUCENE-5377: - Give me some time with the backport, i dont want to introduce another bug here. Will get this all resolved in a few hours. IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5409) ToParentBlockJoinCollector.getTopGroups returns empty Groups
[ https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878809#comment-13878809 ] Peng Cheng commented on LUCENE-5409: Hi Michael, I'll be working on the test case this evening. Thanks a lot for the confirmation. I've read your book. ToParentBlockJoinCollector.getTopGroups returns empty Groups Key: LUCENE-5409 URL: https://issues.apache.org/jira/browse/LUCENE-5409 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.6 Environment: Ubuntu 12.04 Reporter: Peng Cheng Assignee: Michael McCandless Priority: Critical Fix For: 4.7 Original Estimate: 168h Remaining Estimate: 168h A bug is observed to cause unstable results returned by the getTopGroups function of class ToParentBlockJoinCollector. In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the lookup will largely fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). An easy fix would be to rewrite the original BlockJoinQuery before invoking getTopGroups method. However, the computational cost of this is not optimal. A better but slightly more complex solution would be to save unrewrited Queries into the lookup table. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: (Lucene-core) Is Query's rewrite method mandated to preserver original Query's hashcode?
opened as https://issues.apache.org/jira/browse/LUCENE-5409 On Tue, Jan 14, 2014 at 5:42 PM, Uwe Schindler u...@thetaphi.de wrote: Yes, open an issue! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de *From:* Peng Cheng [mailto:p...@sciencescape.net] *Sent:* Tuesday, January 14, 2014 10:41 PM *To:* dev@lucene.apache.org *Subject:* Re: (Lucene-core) Is Query's rewrite method mandated to preserver original Query's hashcode? Do you suggest me to open a jira ticket about it? I think its a bug considering common interface standard (rewrite should not be exposed to the end user), documentation and running efficiency (as you said, rewrite is slow). On Tue, Jan 14, 2014 at 4:38 AM, Peng Cheng p...@sciencescape.net wrote: I see, perhaps the best solution is to put the un-rewritten blockJoinQuries into the joinQueryID? The result will be the same. Right now the code have very strange behavior if no rewrite is called beforehand, it gives empty groups or correct results at random. Its a great pleasure to read your reply, never expect someone to respond that fast. Yours Peng On Tue, Jan 14, 2014 at 2:33 AM, Uwe Schindler u...@thetaphi.de wrote: Hi Peng, rewrite() returns a different query that will definitely not preserve the hashCode() or be equals() to the original one or any other rewritten one. The reason for this is: A rewritten query is a new query that contains information about the index it will be executed on (e.g., it references terms from that index), so it **cannot** be equal to the original one. If it cannot be equal, also the hashCode should be different. If you execute the query on a later stage you have to rewrite the original query again, because the index may have changed. And take care: This rewrite may produce a completely different query (with a new hashCode again) if the index changed in the meantime. As there is a workaround (to me it looks, that the code is missing documentation), so you can manually rewrite the query before invoking getTopGroups() using Searcher#rewrite(query). Why is a hotfix needed? Also rewriting the query on every call of getTopGroups is a major overhead (most query’s rewrites are very expensice and take as long as the execution of the query, e.g. MultiTermQueries), so it should only be done once, not on every call. Maybe that’s the reason why it was left out, but it was not documented. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de *From:* Peng Cheng [mailto:p...@sciencescape.net] *Sent:* Tuesday, January 14, 2014 3:59 AM *To:* dev@lucene.apache.org; d...@sciencescape.org *Subject:* (Lucene-core) Is Query's rewrite method mandated to preserver original Query's hashcode? Hi developers, I've recently found a few bugs in advanced features of Lucene-core 4.6 (which is perfectly normal as those features are less likely to be used and tested), the most serious one has rendered my ToParentBlockJoinCollector close to useless: In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the result (namely _slot) will always fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). I'm not positive about whether rewrite() should preserver Query's hashcode, as I've found many counterexamples already. If this is not true, then this problem can be solved by rewriting the origianl BlockJoinQuery before invoking getTopGroups method. Nevertheless users are not expected to do so, therefore I would suggest submitting a hotfix that add the described rewrite step. If rewrite() must preserver the hashcode, then this is a problem of the various rewrite() implementations and fix should be much harder. This bug has caused widespread panic in my company and I would like to see it fixed ASAP. Please give me some suggestion so I know which hotfix I should be working on. All the best, Yours Peng
RE: (Lucene-core) Is Query's rewrite method mandated to preserver original Query's hashcode?
Thanks! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Peng Cheng [mailto:p...@sciencescape.net] Sent: Wednesday, January 22, 2014 5:23 PM To: dev@lucene.apache.org Subject: Re: (Lucene-core) Is Query's rewrite method mandated to preserver original Query's hashcode? opened as https://issues.apache.org/jira/browse/LUCENE-5409 On Tue, Jan 14, 2014 at 5:42 PM, Uwe Schindler u...@thetaphi.de wrote: Yes, open an issue! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Peng Cheng [mailto:p...@sciencescape.net] Sent: Tuesday, January 14, 2014 10:41 PM To: dev@lucene.apache.org Subject: Re: (Lucene-core) Is Query's rewrite method mandated to preserver original Query's hashcode? Do you suggest me to open a jira ticket about it? I think its a bug considering common interface standard (rewrite should not be exposed to the end user), documentation and running efficiency (as you said, rewrite is slow). On Tue, Jan 14, 2014 at 4:38 AM, Peng Cheng p...@sciencescape.net wrote: I see, perhaps the best solution is to put the un-rewritten blockJoinQuries into the joinQueryID? The result will be the same. Right now the code have very strange behavior if no rewrite is called beforehand, it gives empty groups or correct results at random. Its a great pleasure to read your reply, never expect someone to respond that fast. Yours Peng On Tue, Jan 14, 2014 at 2:33 AM, Uwe Schindler u...@thetaphi.de wrote: Hi Peng, rewrite() returns a different query that will definitely not preserve the hashCode() or be equals() to the original one or any other rewritten one. The reason for this is: A rewritten query is a new query that contains information about the index it will be executed on (e.g., it references terms from that index), so it *cannot* be equal to the original one. If it cannot be equal, also the hashCode should be different. If you execute the query on a later stage you have to rewrite the original query again, because the index may have changed. And take care: This rewrite may produce a completely different query (with a new hashCode again) if the index changed in the meantime. As there is a workaround (to me it looks, that the code is missing documentation), so you can manually rewrite the query before invoking getTopGroups() using Searcher#rewrite(query). Why is a hotfix needed? Also rewriting the query on every call of getTopGroups is a major overhead (most query’s rewrites are very expensice and take as long as the execution of the query, e.g. MultiTermQueries), so it should only be done once, not on every call. Maybe that’s the reason why it was left out, but it was not documented. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de http://www.thetaphi.de/ eMail: u...@thetaphi.de From: Peng Cheng [mailto:p...@sciencescape.net] Sent: Tuesday, January 14, 2014 3:59 AM To: dev@lucene.apache.org; d...@sciencescape.org Subject: (Lucene-core) Is Query's rewrite method mandated to preserver original Query's hashcode? Hi developers, I've recently found a few bugs in advanced features of Lucene-core 4.6 (which is perfectly normal as those features are less likely to be used and tested), the most serious one has rendered my ToParentBlockJoinCollector close to useless: In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the result (namely _slot) will always fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). I'm not positive about whether rewrite() should preserver Query's hashcode, as I've found many counterexamples already. If this is not true, then this problem can be solved by rewriting the origianl BlockJoinQuery before invoking getTopGroups method. Nevertheless users are not expected to do so, therefore I would suggest submitting a hotfix that add the described rewrite step. If rewrite() must preserver the hashcode, then this is a problem of the various rewrite() implementations and fix should be much harder. This bug has caused widespread panic in my company and I would like to see it fixed ASAP. Please give me some suggestion so I know which hotfix I should be working on. All the best, Yours Peng
[jira] [Created] (LUCENE-5413) remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE
Robert Muir created LUCENE-5413: --- Summary: remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE Key: LUCENE-5413 URL: https://issues.apache.org/jira/browse/LUCENE-5413 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 4.7 Somehow we have two impersonation booleans in 4.x. I feel we should only have one. perhaps some logic in a test somewhere needs OLD_FORMAT codec == Lucene3x instead, but having too booleans is not good. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5594) Enable using extended field types with prefix queries for non-default encoded strings
[ https://issues.apache.org/jira/browse/SOLR-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878825#comment-13878825 ] ASF subversion and git services commented on SOLR-5594: --- Commit 1560412 from hoss...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1560412 ] SOLR-5594: Allow FieldTypes to specify custom PrefixQuery behavior Enable using extended field types with prefix queries for non-default encoded strings - Key: SOLR-5594 URL: https://issues.apache.org/jira/browse/SOLR-5594 Project: Solr Issue Type: Improvement Components: query parsers, Schema and Analysis Affects Versions: 4.6 Reporter: Anshum Gupta Assignee: Anshum Gupta Priority: Minor Attachments: SOLR-5594-branch_4x.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch Enable users to be able to use prefix query with custom field types with non-default encoding/decoding for queries more easily. e.g. having a custom field work with base64 encoded query strings. Currently, the workaround for it is to have the override at getRewriteMethod level. Perhaps having the prefixQuery also use the calling FieldType's readableToIndexed method would work better. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: JDK 8 Build 124 JDK 7 Update 60 build 03 are available on java.net
Thanks Uwe! On 22/01/2014 16:14, Uwe Schindler wrote: Hi Rory, I installed both versions. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de http://www.thetaphi.de/ eMail: u...@thetaphi.de *From:*Rory O'Donnell Oracle, Dublin Ireland [mailto:rory.odonn...@oracle.com] *Sent:* Wednesday, January 22, 2014 12:08 PM *To:* Uwe Schindler; Dawid Weiss *Cc:* dev@lucene.apache.org; Dalibor Topic; Cecilia Borg; Balchandra Vaidya *Subject:* JDK 8 Build 124 JDK 7 Update 60 build 03 are available on java.net Hi Uwe/Dawid, JDK 8 Build b124 Early Access Build is now available for download http://jdk8.java.net/download.html test. JDK 7u60 b03 Early Access Build is also available for download https://jdk7.java.net/download.html test. See you at FOSDEM next week. Thanks for your support, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878849#comment-13878849 ] ASF subversion and git services commented on LUCENE-5377: - Commit 1560421 from [~rcmuir] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1560421 ] LUCENE-5377: IW.addIndexes(Dir[]) causes silent index corruption IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878850#comment-13878850 ] Robert Muir commented on LUCENE-5377: - I'll let Jenkins play with the 4.x backport for just a bit before merging back to the release branch. IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5594) Enable using extended field types with prefix queries for non-default encoded strings
[ https://issues.apache.org/jira/browse/SOLR-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878866#comment-13878866 ] ASF subversion and git services commented on SOLR-5594: --- Commit 1560432 from hoss...@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1560432 ] SOLR-5594: Allow FieldTypes to specify custom PrefixQuery behavior (merge r1560412) Enable using extended field types with prefix queries for non-default encoded strings - Key: SOLR-5594 URL: https://issues.apache.org/jira/browse/SOLR-5594 Project: Solr Issue Type: Improvement Components: query parsers, Schema and Analysis Affects Versions: 4.6 Reporter: Anshum Gupta Assignee: Anshum Gupta Priority: Minor Fix For: 5.0, 4.7 Attachments: SOLR-5594-branch_4x.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch Enable users to be able to use prefix query with custom field types with non-default encoding/decoding for queries more easily. e.g. having a custom field work with base64 encoded query strings. Currently, the workaround for it is to have the override at getRewriteMethod level. Perhaps having the prefixQuery also use the calling FieldType's readableToIndexed method would work better. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5594) Enable using extended field types with prefix queries for non-default encoded strings
[ https://issues.apache.org/jira/browse/SOLR-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-5594. Resolution: Fixed Fix Version/s: 4.7 5.0 Thanks Anshum! Committed revision 1560412. Committed revision 1560432. Enable using extended field types with prefix queries for non-default encoded strings - Key: SOLR-5594 URL: https://issues.apache.org/jira/browse/SOLR-5594 Project: Solr Issue Type: Improvement Components: query parsers, Schema and Analysis Affects Versions: 4.6 Reporter: Anshum Gupta Assignee: Anshum Gupta Priority: Minor Fix For: 5.0, 4.7 Attachments: SOLR-5594-branch_4x.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch, SOLR-5594.patch Enable users to be able to use prefix query with custom field types with non-default encoding/decoding for queries more easily. e.g. having a custom field work with base64 encoded query strings. Currently, the workaround for it is to have the override at getRewriteMethod level. Perhaps having the prefixQuery also use the calling FieldType's readableToIndexed method would work better. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878885#comment-13878885 ] Robert Muir commented on LUCENE-5377: - Here is the 4.x backport for review: http://svn.apache.org/r1560421 I'm gonna run the tests a few times more and merge to 4.6 branch IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5653) Create a RESTManager to provide REST API endpoints for reconfigurable plugins
Steve Rowe created SOLR-5653:
Summary: Create a RESTManager to provide REST API endpoints for
reconfigurable plugins
Key: SOLR-5653
URL: https://issues.apache.org/jira/browse/SOLR-5653
Project: Solr
Issue Type: Sub-task
Reporter: Steve Rowe
It should be possible to reconfigure of Solr plugins' resources and init params
without directly editing the serialized schema or {{solrconfig.xml}} (see
Hoss's arguments about this in the context of the schema, which also apply to
{{solrconfig.xml}}, in the description of SOLR-4658)
The RESTManager should allow plugins declared in either the schema or in
{{solrconfig.xml}} to register one or more REST endpoints, one endpoint per
reconfigurable resource, including init params. To allow for multiple plugin
instances, registering plugins will need to provide a handle of some form to
distinguish the instances.
This RESTManager should also be able to create new instances of plugins that it
has been configured to allow. The RESTManager will need its own serialized
configuration to remember these plugin declarations.
Example endpoints:
* SynonymFilterFactory
** init params: {{/solr/collection1/config/syns/myinstance/options}}
** synonyms resource: {{/solr/collection1/config/syns/myinstance/synonyms-list}}
* /select request handler
** init params: {{/solr/collection1/config/requestHandlers/select/options}}
We should aim for full CRUD over init params and structured resources. The
plugins will bear responsibility for handling resource modification requests,
though we should provide utility methods to make this easy.
However, since we won't be directly modifying the serialized schema and
{{solrconfig.xml}}, anything configured in those two places can't be
invalidated by configuration serialized elsewhere. As a result, it won't be
possible to remove plugins declared in the serialized schema or
{{solrconfig.xml}}. Similarly, any init params declared in either place won't
be modifiable. Instead, there should be some form of init param that declares
that the plugin is reconfigurable, maybe using something like managed - note
that request handlers already provide a handle - the request handler name -
and so don't need that to be separately specified:
{code:xml}
requestHandler name=/select class=solr.SearchHandler
managed/
/requestHandler
{code}
and in the serialized schema - a handle needs to be specified here:
{code:xml}
fieldType name=text_general class=solr.TextField
positionIncrementGap=100
...
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.SynonymFilterFactory managed=english-synonyms/
...
{code}
All of the above examples use the existing plugin factory class names, but
we'll have to create new RESTManager-aware classes to handle registration with
RESTManager.
Core/collection reloading should not be performed automatically when a REST API
call is made to one of these RESTManager-mediated REST endpoints, since for
batched config modifications, that could take way too long. But maybe
reloading could be a query parameter to these REST API calls.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5653) Create a RESTManager to provide REST API endpoints for reconfigurable plugins
[
https://issues.apache.org/jira/browse/SOLR-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-5653:
-
Description:
It should be possible to reconfigure Solr plugins' resources and init params
without directly editing the serialized schema or {{solrconfig.xml}} (see
Hoss's arguments about this in the context of the schema, which also apply to
{{solrconfig.xml}}, in the description of SOLR-4658)
The RESTManager should allow plugins declared in either the schema or in
{{solrconfig.xml}} to register one or more REST endpoints, one endpoint per
reconfigurable resource, including init params. To allow for multiple plugin
instances, registering plugins will need to provide a handle of some form to
distinguish the instances.
This RESTManager should also be able to create new instances of plugins that it
has been configured to allow. The RESTManager will need its own serialized
configuration to remember these plugin declarations.
Example endpoints:
* SynonymFilterFactory
** init params: {{/solr/collection1/config/syns/myinstance/options}}
** synonyms resource: {{/solr/collection1/config/syns/myinstance/synonyms-list}}
* /select request handler
** init params: {{/solr/collection1/config/requestHandlers/select/options}}
We should aim for full CRUD over init params and structured resources. The
plugins will bear responsibility for handling resource modification requests,
though we should provide utility methods to make this easy.
However, since we won't be directly modifying the serialized schema and
{{solrconfig.xml}}, anything configured in those two places can't be
invalidated by configuration serialized elsewhere. As a result, it won't be
possible to remove plugins declared in the serialized schema or
{{solrconfig.xml}}. Similarly, any init params declared in either place won't
be modifiable. Instead, there should be some form of init param that declares
that the plugin is reconfigurable, maybe using something like managed - note
that request handlers already provide a handle - the request handler name -
and so don't need that to be separately specified:
{code:xml}
requestHandler name=/select class=solr.SearchHandler
managed/
/requestHandler
{code}
and in the serialized schema - a handle needs to be specified here:
{code:xml}
fieldType name=text_general class=solr.TextField
positionIncrementGap=100
...
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.SynonymFilterFactory managed=english-synonyms/
...
{code}
All of the above examples use the existing plugin factory class names, but
we'll have to create new RESTManager-aware classes to handle registration with
RESTManager.
Core/collection reloading should not be performed automatically when a REST API
call is made to one of these RESTManager-mediated REST endpoints, since for
batched config modifications, that could take way too long. But maybe
reloading could be a query parameter to these REST API calls.
was:
It should be possible to reconfigure of Solr plugins' resources and init params
without directly editing the serialized schema or {{solrconfig.xml}} (see
Hoss's arguments about this in the context of the schema, which also apply to
{{solrconfig.xml}}, in the description of SOLR-4658)
The RESTManager should allow plugins declared in either the schema or in
{{solrconfig.xml}} to register one or more REST endpoints, one endpoint per
reconfigurable resource, including init params. To allow for multiple plugin
instances, registering plugins will need to provide a handle of some form to
distinguish the instances.
This RESTManager should also be able to create new instances of plugins that it
has been configured to allow. The RESTManager will need its own serialized
configuration to remember these plugin declarations.
Example endpoints:
* SynonymFilterFactory
** init params: {{/solr/collection1/config/syns/myinstance/options}}
** synonyms resource: {{/solr/collection1/config/syns/myinstance/synonyms-list}}
* /select request handler
** init params: {{/solr/collection1/config/requestHandlers/select/options}}
We should aim for full CRUD over init params and structured resources. The
plugins will bear responsibility for handling resource modification requests,
though we should provide utility methods to make this easy.
However, since we won't be directly modifying the serialized schema and
{{solrconfig.xml}}, anything configured in those two places can't be
invalidated by configuration serialized elsewhere. As a result, it won't be
possible to remove plugins declared in the serialized schema or
{{solrconfig.xml}}. Similarly, any init params declared in either place won't
be modifiable. Instead, there should be some form of init param that declares
that the plugin is reconfigurable, maybe using something like managed - note
that request handlers already
[jira] [Commented] (SOLR-5641) REST API to modify request handlers
[
https://issues.apache.org/jira/browse/SOLR-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878897#comment-13878897
]
Steve Rowe commented on SOLR-5641:
--
The patch on this issue assumes that {{solrconfig.xml}} is directly modifiable
via REST API, but it shouldn't be - we'll need to make this work with the
RESTManager described in SOLR-5653.
REST API to modify request handlers
---
Key: SOLR-5641
URL: https://issues.apache.org/jira/browse/SOLR-5641
Project: Solr
Issue Type: Sub-task
Reporter: Willy Solaligue
Attachments: SOLR-5641.patch
There should be a REST API to allow modify request handlers.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
Steve Rowe created SOLR-5654: Summary: Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API Key: SOLR-5654 URL: https://issues.apache.org/jira/browse/SOLR-5654 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Reporter: Steve Rowe A synonym filter factory could be (re)configurable via REST API by registering with the RESTManager described in SOLR-5653, and then responding to REST API calls to modify its init params and its synonyms resource file. Read-only (GET) REST API calls should also be provided, both for init params and the synonyms resource file. It should be possible to add/remove/modify one or more entries in the synonyms resource file. We should probably use JSON for the REST request body, as is done in the Schema REST API methods. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878917#comment-13878917 ] Michael McCandless commented on LUCENE-3069: Thanks Mark. Yes, you can see FishEye's comments under Source and and also the All tab. Our (svnpubsub) commit messages are correct here (they say Han Jiang), but the FishEye comments are incorrect (they say Han Lee). Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878932#comment-13878932 ] Mark Miller commented on LUCENE-3069: - Ah, sorry. I'm usually in Comments view and I took Note that all the commit messages at the end of this issue as referring to the ASF subversion and git services commit tags. Given past experience, I don't trust the fisheye or the like integrations. We might wake up one day and they will just be gone along with their history... Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 4.7 Attachments: LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, df-ttf-estimate.txt, example.png FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5656) When using HDFS, the Overseer should have the ability to reassign the cores from failed nodes to running nodes.
Mark Miller created SOLR-5656: - Summary: When using HDFS, the Overseer should have the ability to reassign the cores from failed nodes to running nodes. Key: SOLR-5656 URL: https://issues.apache.org/jira/browse/SOLR-5656 Project: Solr Issue Type: New Feature Reporter: Mark Miller Assignee: Mark Miller Given that the index and transaction logs are in hdfs, it's simple for surviving hardware to take over serving cores for failed hardware. There are some tricky issues around having the Overseer handle this for you, but seems a simple first pass is not too difficult. This will add another alternative to replicating both with hdfs and solr. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5526) Query parser extends standard cause NPE on Solr startup
[
https://issues.apache.org/jira/browse/SOLR-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5526:
---
Attachment: SOLR-5526.patch
minor fixes:
{quote} QParserPlugin.standardPlugins's javadoc needs to point out the
importance of these names being static final so people aren't surprised by
these tests when new parsers are added in the future.{quote}
Added relevant javadocs.
{quote}
TestStandardQParsers is doing something sufficiently odd that it really needs
some javadocs explaining why it exists (ie: mention the class loading problems
associated if there is a standardPlugin that has a non-static, non-final name,
with an {{@see}} this issue, {{@see QParserPlugin.standardPlugins}},
etc...){quote}
Added javadocs
{quote} we should probably make TestStandardQParsers assert that the static
final name it finds in each class matches the name associated in
QParserPlugin.standardPlugins.{quote}
Thats actually what TestStandardQParsers does. Unit test takes classes
registered in QParserPlugin.standardPlugins and ensure that each class has
final and static NAME field.
Added relevant javadocs to TestStandardQParsers.
{quote} solrconfig-query-parser-init.xml has a cut paste comment referring to
an unrelated test.{quote}
Fixed, added relevant comments.
{quote} TestInitQParser should have a javadoc comment explaining what the point
of the test is{quote}
Fixed, added relevant comments.
{quote}TestInitQParser should actaully do a query using the fail parser
registered in the config, to help future-proof us against someone unwittingly
changing the test config in a way that defeats the point of the test.{quote}
This test alerady does query using defType=fail, so i expect this registered
QParser used and return result.
Query parser extends standard cause NPE on Solr startup
---
Key: SOLR-5526
URL: https://issues.apache.org/jira/browse/SOLR-5526
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.5.1, 4.6, 5.0
Environment: Linux, Java 1.7.0_45
Reporter: Nikolay Khitrin
Priority: Blocker
Attachments: NPE_load_trace, SOLR-5526-final-names.patch,
SOLR-5526-final-names.patch, SOLR-5526-tests.patch, SOLR-5526.patch,
SOLR-5526.patch, SOLR-5526.patch
Adding any custom query parser extending standard one with non-final field
{{NAME}} lead to messy {{NullPointerException}} during Solr startup.
Definition of standard parsers is located in
{{QParserPlugin.standardPlugins}} static array. The array contains names from
static {{NAME}} fields and classes for each plugin.
But all of listed parsers are derived from {{QParserPlugin}}, so we have
circular dependency of static fields.
Normally, class loader start initializing {{QParserPlugin}} before all listed
plugins in {{SolrCore.initQParsers}}, and array elements referenced to
{{NAME}} plugins' fields are filled properly.
Custom parsers are instantiated before standard parsers. And when we subclass
plugin with non-final {{NAME}} field and add it to Solr via
{{solrconfig.xml}}, class loader start loading our class before
{{QParserPlugin}}. Because {{QParserPlugin}} is a superclass for plugin, it
must be initialized before subclasses, and static dereferencing cause null
elements in {{standardPlugins}} array because it filled before {{NAME}} field
of loading plugin's superclass.
How to reproduce:
# Checkout Solr (trunk or stable)
# Add the following line to solr/example/solr/collection1/conf/solrconfig.xml
{{queryParser name=fail class=solr.search.LuceneQParserPlugin/}}
# Call ant run-example in solr folder
Possible workarounds:
* dev-workaround: add {{int workaround =
QParserPlugin.standardPlugins.length;}} as a first line to
{{SolrCore.initQParsers}}
* user-workaround: add plugin with final {{NAME}} field (edismax) to
solrconfig.xml before subclasses of standard plugins.
{{queryParser name=workaround
class=solr.search.ExtendedDismaxQParserPlugin/}}
Possible fix:
Move {{standardPlugins}} to new final class to break circular dependency.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5655) Create a stopword filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
Steve Rowe created SOLR-5655: Summary: Create a stopword filter factory that is (re)configurable, and capable of reporting its configuration, via REST API Key: SOLR-5655 URL: https://issues.apache.org/jira/browse/SOLR-5655 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Reporter: Steve Rowe A stopword filter factory could be (re)configurable via REST API by registering with the RESTManager described in SOLR-5653, and then responding to REST API calls to modify its init params and its stopwords resource file. Read-only (GET) REST API calls should also be provided, both for init params and the stopwords resource file. It should be possible to add/remove one or more entries in the stopwords resource file. We should probably use JSON for the REST request body, as is done in the Schema REST API methods. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5657) When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode.
Mark Miller created SOLR-5657: - Summary: When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode. Key: SOLR-5657 URL: https://issues.apache.org/jira/browse/SOLR-5657 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Currently, things just fail. Ideally, the SolrCore would wait until safe mode was exited and resume loading. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
[ https://issues.apache.org/jira/browse/SOLR-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878957#comment-13878957 ] Robert Muir commented on SOLR-5654: --- Why do we need new factories for synonyms and stopwords? I dont understand this design at all, this seems like duplication of all the analysis factories! Instead, just pass a different resourceloader or something to the existing ones! Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API -- Key: SOLR-5654 URL: https://issues.apache.org/jira/browse/SOLR-5654 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Reporter: Steve Rowe A synonym filter factory could be (re)configurable via REST API by registering with the RESTManager described in SOLR-5653, and then responding to REST API calls to modify its init params and its synonyms resource file. Read-only (GET) REST API calls should also be provided, both for init params and the synonyms resource file. It should be possible to add/remove/modify one or more entries in the synonyms resource file. We should probably use JSON for the REST request body, as is done in the Schema REST API methods. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
[ https://issues.apache.org/jira/browse/SOLR-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878969#comment-13878969 ] Michael McCandless commented on SOLR-5654: -- In Lucene server (LUCENE-5376) I just created a custom ResourceLoader to pull stopwords that were specified (inlined) in the JSON when the field is registered. But separately I think it's ... dangerous to allow changing stopwords / syns on an already created field / running index? Ie, such changes won't fully take effect until you re-index all content ... I know it's convenient to be able to make such changes, but it's also trappy. Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API -- Key: SOLR-5654 URL: https://issues.apache.org/jira/browse/SOLR-5654 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Reporter: Steve Rowe A synonym filter factory could be (re)configurable via REST API by registering with the RESTManager described in SOLR-5653, and then responding to REST API calls to modify its init params and its synonyms resource file. Read-only (GET) REST API calls should also be provided, both for init params and the synonyms resource file. It should be possible to add/remove/modify one or more entries in the synonyms resource file. We should probably use JSON for the REST request body, as is done in the Schema REST API methods. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
[
https://issues.apache.org/jira/browse/SOLR-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879015#comment-13879015
]
Steve Rowe commented on SOLR-5654:
--
{quote}
Why do we need new factories for synonyms and stopwords? I dont understand this
design at all, this seems like duplication of all the analysis factories!
Instead, just pass a different resourceloader or something to the existing ones!
{quote}
The point of this issue is to provide REST API methods to interrogate and
modify/persist synonym config and mappings. A different resourceloader would
only allow for this info to be pulled from an alternate persistence store - it
wouldn't do anything for the REST API and persistence part.
{quote}
But separately I think it's ... dangerous to allow changing stopwords / syns on
an already created field / running index? Ie, such changes won't fully take
effect until you re-index all content ... I know it's convenient to be able to
make such changes, but it's also trappy.
{quote}
That's already true today for people who manually modify config and
restart/reload. I guess your point is that we shouldn't be making this easier.
I disagree: the point of the issue is to allow people more fine-grained
control over an already-existing freedom. I think documentation warning people
about the danger of modifying config with an existing index is sufficient to
help people who want this capability avoid creating indexes with mixed analysis
config.
Create a synonym filter factory that is (re)configurable, and capable of
reporting its configuration, via REST API
--
Key: SOLR-5654
URL: https://issues.apache.org/jira/browse/SOLR-5654
Project: Solr
Issue Type: Sub-task
Components: Schema and Analysis
Reporter: Steve Rowe
A synonym filter factory could be (re)configurable via REST API by
registering with the RESTManager described in SOLR-5653, and then responding
to REST API calls to modify its init params and its synonyms resource file.
Read-only (GET) REST API calls should also be provided, both for init params
and the synonyms resource file.
It should be possible to add/remove/modify one or more entries in the
synonyms resource file.
We should probably use JSON for the REST request body, as is done in the
Schema REST API methods.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-5377. - Resolution: Fixed Thank you very much Littlestar. What a terrible bug! IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5377) IW.addIndexes(Dir[]) causes silent index corruption
[ https://issues.apache.org/jira/browse/LUCENE-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879024#comment-13879024 ] ASF subversion and git services commented on LUCENE-5377: - Commit 1560477 from [~rcmuir] in branch 'dev/branches/lucene_solr_4_6' [ https://svn.apache.org/r1560477 ] LUCENE-5377: IW.addIndexes(Dir[]) causes silent index corruption IW.addIndexes(Dir[]) causes silent index corruption --- Key: LUCENE-5377 URL: https://issues.apache.org/jira/browse/LUCENE-5377 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 4.6 Environment: windows/linux Reporter: Littlestar Assignee: Robert Muir Fix For: 5.0, 4.7, 4.6.1 Attachments: LUCENE-5377.patch, LUCENE-5377.patch, TestCore_45.java, TestCore_46.java my old facet index create by Lucene version=4.2 use indexChecker ok. now I upgrade to Lucene 4.6 and put some new records to index. then reopen index, some files in indexdir missing no .si files. I debug into it, new version format of segments.gen(segments_N) record bad segments info. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-5228) IndexWriter.addIndexes copies raw files but acquires no locks
[ https://issues.apache.org/jira/browse/LUCENE-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-5228: -- Assignee: Michael McCandless IndexWriter.addIndexes copies raw files but acquires no locks - Key: LUCENE-5228 URL: https://issues.apache.org/jira/browse/LUCENE-5228 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Assignee: Michael McCandless Attachments: LUCENE-5228.patch I see stuff like: merge problem with lucene 3 and 4 indices (from solr users list), and cannot even think how to respond to these users because so many things can go wrong with IndexWriter.addIndexes(Directory) it currently has in its javadocs: NOTE: the index in each Directory must not be changed (opened by a writer) while this method is running. This method does not acquire a write lock in each input Directory, so it is up to the caller to enforce this. This method should be acquiring locks: its copying *RAW FILES*. Otherwise we should remove it. If someone doesnt like that, or is mad because its 10ns slower, they can use NoLockFactory. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5228) IndexWriter.addIndexes copies raw files but acquires no locks
[ https://issues.apache.org/jira/browse/LUCENE-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5228: --- Attachment: LUCENE-5228.patch How about something like this? I fixed Lock to implement Closeable, and just added the acquire/close inside IW.addIndexes(Dir[]). IndexWriter.addIndexes copies raw files but acquires no locks - Key: LUCENE-5228 URL: https://issues.apache.org/jira/browse/LUCENE-5228 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Assignee: Michael McCandless Attachments: LUCENE-5228.patch I see stuff like: merge problem with lucene 3 and 4 indices (from solr users list), and cannot even think how to respond to these users because so many things can go wrong with IndexWriter.addIndexes(Directory) it currently has in its javadocs: NOTE: the index in each Directory must not be changed (opened by a writer) while this method is running. This method does not acquire a write lock in each input Directory, so it is up to the caller to enforce this. This method should be acquiring locks: its copying *RAW FILES*. Otherwise we should remove it. If someone doesnt like that, or is mad because its 10ns slower, they can use NoLockFactory. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5413) remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE
[ https://issues.apache.org/jira/browse/LUCENE-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5413: Attachment: LUCENE-5413.patch patch: this only applies to branch_4x (trunk is not impacted, as it does not support 3.x indexes) remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE - Key: LUCENE-5413 URL: https://issues.apache.org/jira/browse/LUCENE-5413 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 4.7 Attachments: LUCENE-5413.patch Somehow we have two impersonation booleans in 4.x. I feel we should only have one. perhaps some logic in a test somewhere needs OLD_FORMAT codec == Lucene3x instead, but having too booleans is not good. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5228) IndexWriter.addIndexes copies raw files but acquires no locks
[ https://issues.apache.org/jira/browse/LUCENE-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879184#comment-13879184 ] Robert Muir commented on LUCENE-5228: - Very simple approach! I like it. IndexWriter.addIndexes copies raw files but acquires no locks - Key: LUCENE-5228 URL: https://issues.apache.org/jira/browse/LUCENE-5228 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Assignee: Michael McCandless Attachments: LUCENE-5228.patch I see stuff like: merge problem with lucene 3 and 4 indices (from solr users list), and cannot even think how to respond to these users because so many things can go wrong with IndexWriter.addIndexes(Directory) it currently has in its javadocs: NOTE: the index in each Directory must not be changed (opened by a writer) while this method is running. This method does not acquire a write lock in each input Directory, so it is up to the caller to enforce this. This method should be acquiring locks: its copying *RAW FILES*. Otherwise we should remove it. If someone doesnt like that, or is mad because its 10ns slower, they can use NoLockFactory. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5413) remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE
[ https://issues.apache.org/jira/browse/LUCENE-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5413: Attachment: LUCENE-5413.patch fix a couple test bugs in the first patch remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE - Key: LUCENE-5413 URL: https://issues.apache.org/jira/browse/LUCENE-5413 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 4.7 Attachments: LUCENE-5413.patch, LUCENE-5413.patch Somehow we have two impersonation booleans in 4.x. I feel we should only have one. perhaps some logic in a test somewhere needs OLD_FORMAT codec == Lucene3x instead, but having too booleans is not good. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5413) remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE
[ https://issues.apache.org/jira/browse/LUCENE-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879200#comment-13879200 ] Michael McCandless commented on LUCENE-5413: +1 to the last patch! remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE - Key: LUCENE-5413 URL: https://issues.apache.org/jira/browse/LUCENE-5413 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 4.7 Attachments: LUCENE-5413.patch, LUCENE-5413.patch Somehow we have two impersonation booleans in 4.x. I feel we should only have one. perhaps some logic in a test somewhere needs OLD_FORMAT codec == Lucene3x instead, but having too booleans is not good. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
[
https://issues.apache.org/jira/browse/SOLR-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879204#comment-13879204
]
Robert Muir commented on SOLR-5654:
---
{quote}
The point of this issue is to provide REST API methods to interrogate and
modify/persist synonym config and mappings. A different resourceloader would
only allow for this info to be pulled from an alternate persistence store - it
wouldn't do anything for the REST API and persistence part.
{quote}
It wouldnt prevent it either.
Reworded: why is a custom factory necessary?
Create a synonym filter factory that is (re)configurable, and capable of
reporting its configuration, via REST API
--
Key: SOLR-5654
URL: https://issues.apache.org/jira/browse/SOLR-5654
Project: Solr
Issue Type: Sub-task
Components: Schema and Analysis
Reporter: Steve Rowe
A synonym filter factory could be (re)configurable via REST API by
registering with the RESTManager described in SOLR-5653, and then responding
to REST API calls to modify its init params and its synonyms resource file.
Read-only (GET) REST API calls should also be provided, both for init params
and the synonyms resource file.
It should be possible to add/remove/modify one or more entries in the
synonyms resource file.
We should probably use JSON for the REST request body, as is done in the
Schema REST API methods.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5413) remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE
[ https://issues.apache.org/jira/browse/LUCENE-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-5413. - Resolution: Fixed remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE - Key: LUCENE-5413 URL: https://issues.apache.org/jira/browse/LUCENE-5413 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 4.7 Attachments: LUCENE-5413.patch, LUCENE-5413.patch Somehow we have two impersonation booleans in 4.x. I feel we should only have one. perhaps some logic in a test somewhere needs OLD_FORMAT codec == Lucene3x instead, but having too booleans is not good. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5413) remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE
[ https://issues.apache.org/jira/browse/LUCENE-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879207#comment-13879207 ] ASF subversion and git services commented on LUCENE-5413: - Commit 1560519 from [~rcmuir] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1560519 ] LUCENE-5413: remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE remove LuceneTestCase.PREFLEX_IMPERSONATION_IS_ACTIVE - Key: LUCENE-5413 URL: https://issues.apache.org/jira/browse/LUCENE-5413 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 4.7 Attachments: LUCENE-5413.patch, LUCENE-5413.patch Somehow we have two impersonation booleans in 4.x. I feel we should only have one. perhaps some logic in a test somewhere needs OLD_FORMAT codec == Lucene3x instead, but having too booleans is not good. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5657) When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode.
[ https://issues.apache.org/jira/browse/SOLR-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5657: -- Attachment: SOLR-5657.patch When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode. Key: SOLR-5657 URL: https://issues.apache.org/jira/browse/SOLR-5657 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5657.patch Currently, things just fail. Ideally, the SolrCore would wait until safe mode was exited and resume loading. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5654) Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API
[ https://issues.apache.org/jira/browse/SOLR-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879209#comment-13879209 ] Michael McCandless commented on SOLR-5654: -- bq. I guess your point is that we shouldn't be making this easier. Right. bq. I disagree: the point of the issue is to allow people more fine-grained control over an already-existing freedom. Just because there's already an existing (not necessarily good) freedom doesn't mean it must be made easier. Optimize is an existing freedom :) Does Solr at least record somewhere that full re-index required? So the user (if s/he knows to look in the right place on the admin UI) is informed that inconsistent results might be because they didn't fully re-index yet... Create a synonym filter factory that is (re)configurable, and capable of reporting its configuration, via REST API -- Key: SOLR-5654 URL: https://issues.apache.org/jira/browse/SOLR-5654 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Reporter: Steve Rowe A synonym filter factory could be (re)configurable via REST API by registering with the RESTManager described in SOLR-5653, and then responding to REST API calls to modify its init params and its synonyms resource file. Read-only (GET) REST API calls should also be provided, both for init params and the synonyms resource file. It should be possible to add/remove/modify one or more entries in the synonyms resource file. We should probably use JSON for the REST request body, as is done in the Schema REST API methods. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5657) When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode.
[ https://issues.apache.org/jira/browse/SOLR-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5657: -- Fix Version/s: 4.7 5.0 When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode. Key: SOLR-5657 URL: https://issues.apache.org/jira/browse/SOLR-5657 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5657.patch Currently, things just fail. Ideally, the SolrCore would wait until safe mode was exited and resume loading. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5657) When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode.
[ https://issues.apache.org/jira/browse/SOLR-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879210#comment-13879210 ] Mark Miller commented on SOLR-5657: --- This significantly improves how the various hdfs components handle running into safe mode on startup. Also includes random testing that hits HdfsLockFactory, HdfsDirectory, and HdfsUpdateLog. When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode. Key: SOLR-5657 URL: https://issues.apache.org/jira/browse/SOLR-5657 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5657.patch Currently, things just fail. Ideally, the SolrCore would wait until safe mode was exited and resume loading. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5410) Add fuzziness support to SimpleQueryParser
[
https://issues.apache.org/jira/browse/LUCENE-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lee Hinman updated LUCENE-5410:
---
Attachment: LUCENE-5410.patch
Attached patch that supports both edit distance for single terms and slop for
phrases.
I chose to add only a single flag ({{FUZZINESS_OPERATOR}}) for
enabling/disabling both behaviors, but it would be easy to separate them if
desired.
Add fuzziness support to SimpleQueryParser
--
Key: LUCENE-5410
URL: https://issues.apache.org/jira/browse/LUCENE-5410
Project: Lucene - Core
Issue Type: Improvement
Components: core/queryparser
Affects Versions: 4.7
Reporter: Lee Hinman
Priority: Minor
Attachments: LUCENE-5410.patch
Original Estimate: 168h
Remaining Estimate: 168h
It would be nice to add fuzzy query support to the {{SimpleQueryParser}} so
that:
{{foo~2}}
generates a {{FuzzyQuery}} with an max edit distance of 2 and:
{{foo bar~2}}
generates a {{PhraseQuery}} with a slop of 2.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5657) When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode.
[ https://issues.apache.org/jira/browse/SOLR-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879288#comment-13879288 ] ASF subversion and git services commented on SOLR-5657: --- Commit 1560553 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1560553 ] SOLR-5657: When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode. When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode. Key: SOLR-5657 URL: https://issues.apache.org/jira/browse/SOLR-5657 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5657.patch Currently, things just fail. Ideally, the SolrCore would wait until safe mode was exited and resume loading. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5657) When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode.
[ https://issues.apache.org/jira/browse/SOLR-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879289#comment-13879289 ] ASF subversion and git services commented on SOLR-5657: --- Commit 1560554 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1560554 ] SOLR-5657: When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode. When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode. Key: SOLR-5657 URL: https://issues.apache.org/jira/browse/SOLR-5657 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5657.patch Currently, things just fail. Ideally, the SolrCore would wait until safe mode was exited and resume loading. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5410) Add fuzziness support to SimpleQueryParser
[
https://issues.apache.org/jira/browse/LUCENE-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879319#comment-13879319
]
Robert Muir commented on LUCENE-5410:
-
Hi Lee, in general this seems like a good approach.
Can we avoid the changes to QueryBuilder? The purpose of QueryBuilder is to
interact with the analysis chain, and thats not typically how fuzzy queries are
handled (for the same reason QueryBuilder has no prefix logic, so I think the
case should be handled in a similar fashion). This way we can avoid adding
methods like createFuzzyBooleanQuery, newTermOrFuzzyQuery and so on.
As far as the parser itself, I don't like having both newPhraseQuery(String)
and newPhraseQuery(String, int). Can we just nuke the first one and have the
latter instead? Exact phrase queries can just past 0 here.
Can we add the tilde operator to the list in testRandomQueries2 ?
Add fuzziness support to SimpleQueryParser
--
Key: LUCENE-5410
URL: https://issues.apache.org/jira/browse/LUCENE-5410
Project: Lucene - Core
Issue Type: Improvement
Components: core/queryparser
Affects Versions: 4.7
Reporter: Lee Hinman
Priority: Minor
Attachments: LUCENE-5410.patch
Original Estimate: 168h
Remaining Estimate: 168h
It would be nice to add fuzzy query support to the {{SimpleQueryParser}} so
that:
{{foo~2}}
generates a {{FuzzyQuery}} with an max edit distance of 2 and:
{{foo bar~2}}
generates a {{PhraseQuery}} with a slop of 2.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Artifacts-4.x - Build # 534 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-4.x/534/ No tests ran. Build Log: [...truncated 6284 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-4.x/lucene/build.xml:543: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-4.x/lucene/common-build.xml:2352: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /usr/home/hudson/hudson-slave/workspace/Lucene-Artifacts-4.x/lucene/build/docs/changes/jiraVersionList.json Total time: 5 minutes 33 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Publishing Javadoc Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #570: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/570/ No tests ran. Build Log: [...truncated 6624 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:475: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:153: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/lucene/common-build.xml:539: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/lucene/common-build.xml:536: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/lucene/build.xml:543: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/lucene/common-build.xml:2352: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/lucene/build/docs/changes/jiraVersionList.json Total time: 5 minutes 34 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_51) - Build # 3702 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3702/ Java: 64bit/jdk1.7.0_51 -XX:+UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 52343 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:453: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:57: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:208: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:543: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:2321: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\docs\changes\jiraVersionList.json Total time: 112 minutes 6 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.7.0_51 -XX:+UseCompressedOops -XX:+UseG1GC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Areek Zillur as Lucene/Solr committer!
Welcome, Areek! koji -- http://soleami.com/blog/mahout-and-machine-learning-training-course-is-here.html (14/01/22 4:26), Robert Muir wrote: I'm pleased to announce that Areek Zillur has accepted to join our ranks as a committer. Areek has been improving suggester support in Lucene and Solr, including a revamped Solr component slated for the 4.7 release. [1] Areek, it is tradition that you introduce yourself with a brief bio. Once your account is setup, you should then be able to add yourself to the who we are page on the website as well. Congratulations and welcome! [1] https://issues.apache.org/jira/browse/SOLR-5378 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.7.0_60-ea-b03) - Build # 3626 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/3626/ Java: 64bit/jdk1.7.0_60-ea-b03 -XX:+UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 41961 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.compressing... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene41... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene42... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene45... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene46... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_60-ea [javadoc] Building tree for all the packages and classes... [javadoc] Generating C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\docs\core\org\apache\lucene\search\package-summary.html... [javadoc] Copying file C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\core\src\java\org\apache\lucene\search\doc-files\nrq-formula-1.png to directory C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\docs\core\org\apache\lucene\search\doc-files... [javadoc] Copying file C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\core\src\java\org\apache\lucene\search\doc-files\nrq-formula-2.png to directory C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\docs\core\org\apache\lucene\search\doc-files... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\docs\core\help-doc.html... [javadoc] 1 warning [...truncated 27 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.analysis.ar... [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javadoc] Loading source files for package org.apache.lucene.analysis.bg... [javadoc] Loading source files for package org.apache.lucene.analysis.br... [javadoc] Loading source files for package org.apache.lucene.analysis.ca... [javadoc] Loading source files for package org.apache.lucene.analysis.charfilter... [javadoc] Loading source files for package org.apache.lucene.analysis.cjk... [javadoc] Loading source files for package org.apache.lucene.analysis.ckb... [javadoc] Loading source files for package org.apache.lucene.analysis.cn... [javadoc] Loading source files for package org.apache.lucene.analysis.commongrams... [javadoc] Loading source files for package org.apache.lucene.analysis.compound... [javadoc] Loading source files for package org.apache.lucene.analysis.compound.hyphenation... [javadoc] Loading source files for package org.apache.lucene.analysis.core... [javadoc] Loading source files for package org.apache.lucene.analysis.cz... [javadoc] Loading source files for package org.apache.lucene.analysis.da... [javadoc] Loading source files for package org.apache.lucene.analysis.de... [javadoc] Loading source files for package org.apache.lucene.analysis.el... [javadoc] Loading source files for package org.apache.lucene.analysis.en... [javadoc] Loading source files for package
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 74595 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/74595/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestSearchAfter.testQueries Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([3A4880EB941822D6:66C64C308E719778]:0) at org.apache.lucene.search.TopFieldCollector$PagingFieldCollector.collect(TopFieldCollector.java:982) at org.apache.lucene.search.Scorer.score(Scorer.java:65) at org.apache.lucene.search.AssertingScorer.score(AssertingScorer.java:136) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:613) at org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:93) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:573) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:525) at org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:416) at org.apache.lucene.search.TestSearchAfter.assertQuery(TestSearchAfter.java:259) at org.apache.lucene.search.TestSearchAfter.assertQuery(TestSearchAfter.java:205) at org.apache.lucene.search.TestSearchAfter.testQueries(TestSearchAfter.java:189) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at 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
Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 74595 - Failure!
1. this doesnt reproduce.
2. the line of the NPE makes no sense: its this code,
if (queueFull) {
queueFull is a primitive type (boolean)...
On Wed, Jan 22, 2014 at 8:41 PM, buil...@flonkings.com wrote:
Build:
builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/74595/
1 tests failed.
REGRESSION: org.apache.lucene.search.TestSearchAfter.testQueries
Error Message:
Stack Trace:
java.lang.NullPointerException
at
__randomizedtesting.SeedInfo.seed([3A4880EB941822D6:66C64C308E719778]:0)
at
org.apache.lucene.search.TopFieldCollector$PagingFieldCollector.collect(TopFieldCollector.java:982)
at org.apache.lucene.search.Scorer.score(Scorer.java:65)
at
org.apache.lucene.search.AssertingScorer.score(AssertingScorer.java:136)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:613)
at
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:93)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:573)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:525)
at
org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:416)
at
org.apache.lucene.search.TestSearchAfter.assertQuery(TestSearchAfter.java:259)
at
org.apache.lucene.search.TestSearchAfter.assertQuery(TestSearchAfter.java:205)
at
org.apache.lucene.search.TestSearchAfter.testQueries(TestSearchAfter.java:189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at
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
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b124) - Build # 9200 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9200/ Java: 64bit/jdk1.8.0-ea-b124 -XX:-UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 42833 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:453: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:57: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:208: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:543: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2321: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/changes/jiraVersionList.json Total time: 60 minutes 14 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.8.0-ea-b124 -XX:-UseCompressedOops -XX:+UseG1GC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
