[jira] Closed: (LUCENE-1399) NullPointerException issue with single IndexWriter instance shared among multiple Thread
[
https://issues.apache.org/jira/browse/LUCENE-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudi Quark closed LUCENE-1399.
--
Resolution: Fixed
Fix Version/s: 2.4
This issue seems to be fixed by 2.4 version.
NullPointerException issue with single IndexWriter instance shared among
multiple Thread
Key: LUCENE-1399
URL: https://issues.apache.org/jira/browse/LUCENE-1399
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.3.2
Environment: Windows XP, JDK 1.6
Reporter: Rudi Quark
Fix For: 2.4
NullPointerException is thrown while indexing within multiple threads but
using one single IndexWriter instance. According to Lucene in Action this
should do: ...a single instance of either class can be shared among multiple
threads, and all calls to its index-modifying methods will be properly
synchronized so that index modifications are executed one after the other.
Following my exception trace:
java.lang.NullPointerException
at
org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:475)
at
org.apache.lucene.index.IndexWriter.commitTransaction(IndexWriter.java:1986)
at org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:2219)
at
com.shi.marketingspy.test.SHILuceneWritingFromThreadsTest$testthread.run(SHILuceneWritingFromThreadsTest.java:48)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Following my test program:
package com.shi.marketingspy.test;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.document.Field.Store;
import org.apache.lucene.index.IndexWriter;
public class SHILuceneWritingFromThreadsTest
{
public static void log(String s, com.shi.jipmisc misc)
{
misc.__Log(s);
}
public static class testthread implements Runnable
{
public org.apache.lucene.index.IndexWriter indexwriter;
public int iThread;
public boolean bWithOptimize;
public com.shi.jipmisc misc;
public testthread(org.apache.lucene.index.IndexWriter
indexwriter, int iThread, boolean bWithOptimize, com.shi.jipmisc misc)
{
this.indexwriter= indexwriter;
this.iThread= iThread;
this.bWithOptimize = bWithOptimize;
this.misc = misc;
}
public void run()
{
try
{
Analyzer anal = new
com.shi.lucene.index.SHIAnalyser(null,null);
org.apache.lucene.store.Directory tmpidxdirectory
= new org.apache.lucene.store.RAMDirectory();
org.apache.lucene.index.IndexWriter tempindexwriter =
new IndexWriter(tmpidxdirectory, anal, true);
Document doc = new Document();
for(int ifld=0; ifld 9; ifld++)
{
doc.add(new Field(field_+ifld, iThread:
+iThread+ field: +ifld+ +System.currentTimeMillis()+
+misc.getDateString()+ +misc.getDateString2()+
+com.shi.jipmisc.getTimeStamp()+ +misc.getClass()+ +misc.getDebug(),
Store.COMPRESS, Field.Index.UN_TOKENIZED));
}
tempindexwriter.addDocument(doc);
tempindexwriter.optimize();
org.apache.lucene.store.Directory[] idxs = new
org.apache.lucene.store.Directory[1];
idxs[0] = tmpidxdirectory;
//todo: del-call...
this.indexwriter.addIndexes(idxs);
if (this.bWithOptimize)
this.indexwriter.optimize();
}
catch(Throwable e)
{
log(testthread:run\tERR:2(bWithOpti:+bWithOptimize+)(iThread:+iThread+):+e.getMessage()+\n\t+com.shi.jipmisc.stack2string(e),
misc);
}
}
}
public SHILuceneWritingFromThreadsTest()
{
}
public static void main(String[] args)
{
testluceneconcurrency(false);
testluceneconcurrency(true );
}
public static java.util.concurrent.ExecutorService threadpool_optimized
= java.util.concurrent.Executors.newFixedThreadPool(999);
public static
[jira] Commented: (LUCENE-1342) 64bit JVM crashes on Linux
[ https://issues.apache.org/jira/browse/LUCENE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633653#action_12633653 ] Michael McCandless commented on LUCENE-1342: Sorry -- I don't know which specific JRE bug this is. It'd be good to test if it's the same JRE bug behind LUCENE-1282 and if not, try to further isolate/characterize it (after upgrading to the lastest JRE 1.6 release). 64bit JVM crashes on Linux -- Key: LUCENE-1342 URL: https://issues.apache.org/jira/browse/LUCENE-1342 Project: Lucene - Java Issue Type: Bug Affects Versions: 2.0.0 Environment: 2.6.18-53.el5 x86_64 GNU/Linux Java(TM) SE Runtime Environment (build 1.6.0_04-b12) Reporter: Kevin Richards Whilst running lucene in our QA environment we received the following exception. This problem was also reported here : http://confluence.atlassian.com/display/KB/JSP-20240+-+POSSIBLE+64+bit+JDK+1.6+update+4+may+have+HotSpot+problems. Is this a JVM problem or a problem in Lucene. # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2adb9e3f, pid=2275, tid=1085356352 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b19 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x1fce3f] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --- T H R E A D --- Current thread (0x2aab0007f000): JavaThread CompilerThread0 daemon [_thread_in_vm, id=2301, stack(0x40a13000,0x40b14000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x Registers: RAX=0x, RBX=0x2aab0007f000, RCX=0x, RDX=0x2aab00309aa0 RSP=0x40b10f60, RBP=0x40b10fb0, RSI=0x2aaab37d1ce8, RDI=0x2aaad000 R8 =0x2b40cd88, R9 =0x0ffc, R10=0x2b40cd90, R11=0x2b410810 R12=0x2aab00ae60b0, R13=0x2aab0a19cc30, R14=0x40b112f0, R15=0x2aab00ae60b0 RIP=0x2adb9e3f, EFL=0x00010246, CSGSFS=0x0033, ERR=0x0004 TRAPNO=0x000e Top of Stack: (sp=0x40b10f60) 0x40b10f60: 2aab0007f000 0x40b10f70: 2aab0a19cc30 0001 0x40b10f80: 2aab0007f000 0x40b10f90: 40b10fe0 2aab0a19cc30 0x40b10fa0: 2aab0a19cc30 2aab00ae60b0 0x40b10fb0: 40b10fe0 2ae9c2e4 0x40b10fc0: 2b413210 2b413350 0x40b10fd0: 40b112f0 2aab09796260 0x40b10fe0: 40b110e0 2ae9d7d8 0x40b10ff0: 2b40f3d0 2aab08c2a4c8 0x40b11000: 40b11940 2aab09796260 0x40b11010: 2aab09795b28 0x40b11020: 2aab08c2a4c8 2aab009b9750 0x40b11030: 2aab09796260 40b11940 0x40b11040: 2b40f3d0 2023 0x40b11050: 40b11940 2aab09796260 0x40b11060: 40b11090 2b0f199e 0x40b11070: 40b11978 2aab08c2a458 0x40b11080: 2b413210 2023 0x40b11090: 40b110e0 2b0f1fcf 0x40b110a0: 2023 2aab09796260 0x40b110b0: 2aab08c2a3c8 40b123b0 0x40b110c0: 2aab08c2a458 40b112f0 0x40b110d0: 2b40f3d0 2aab00043670 0x40b110e0: 40b11160 2b0e808d 0x40b110f0: 2aab000417c0 2aab009b66a8 0x40b11100: 2aab009b9750 0x40b0: 40b112f0 2aab009bb360 0x40b11120: 0003 40b113d0 0x40b11130: 01002aab0052d0c0 40b113d0 0x40b11140: 00b3 40b112f0 0x40b11150: 40b113d0 2aab08c2a108 Instructions: (pc=0x2adb9e3f) 0x2adb9e2f: 48 89 5d b0 49 8b 55 08 49 8b 4c 24 08 48 8b 32 0x2adb9e3f: 4c 8b 21 8b 4e 1c 49 8d 7c 24 10 89 cb 4a 39 34 Stack: [0x40a13000,0x40b14000], sp=0x40b10f60, free space=1015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1fce3f] V [libjvm.so+0x2df2e4] V [libjvm.so+0x2e07d8] V [libjvm.so+0x52b08d] V [libjvm.so+0x524914] V [libjvm.so+0x51c0ea] V [libjvm.so+0x519f77] V [libjvm.so+0x519e7c] V [libjvm.so+0x519ad5] V [libjvm.so+0x1e0cf4] V [libjvm.so+0x2a0bc0] V [libjvm.so+0x528e03] V [libjvm.so+0x51c0ea] V [libjvm.so+0x519f77] V [libjvm.so+0x519e7c] V
[jira] Commented: (LUCENE-1399) NullPointerException issue with single IndexWriter instance shared among multiple Thread
[
https://issues.apache.org/jira/browse/LUCENE-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633654#action_12633654
]
Michael McCandless commented on LUCENE-1399:
Super thanks Rudi!
NullPointerException issue with single IndexWriter instance shared among
multiple Thread
Key: LUCENE-1399
URL: https://issues.apache.org/jira/browse/LUCENE-1399
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.3.2
Environment: Windows XP, JDK 1.6
Reporter: Rudi Quark
Fix For: 2.4
NullPointerException is thrown while indexing within multiple threads but
using one single IndexWriter instance. According to Lucene in Action this
should do: ...a single instance of either class can be shared among multiple
threads, and all calls to its index-modifying methods will be properly
synchronized so that index modifications are executed one after the other.
Following my exception trace:
java.lang.NullPointerException
at
org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:475)
at
org.apache.lucene.index.IndexWriter.commitTransaction(IndexWriter.java:1986)
at org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:2219)
at
com.shi.marketingspy.test.SHILuceneWritingFromThreadsTest$testthread.run(SHILuceneWritingFromThreadsTest.java:48)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Following my test program:
package com.shi.marketingspy.test;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.document.Field.Store;
import org.apache.lucene.index.IndexWriter;
public class SHILuceneWritingFromThreadsTest
{
public static void log(String s, com.shi.jipmisc misc)
{
misc.__Log(s);
}
public static class testthread implements Runnable
{
public org.apache.lucene.index.IndexWriter indexwriter;
public int iThread;
public boolean bWithOptimize;
public com.shi.jipmisc misc;
public testthread(org.apache.lucene.index.IndexWriter
indexwriter, int iThread, boolean bWithOptimize, com.shi.jipmisc misc)
{
this.indexwriter= indexwriter;
this.iThread= iThread;
this.bWithOptimize = bWithOptimize;
this.misc = misc;
}
public void run()
{
try
{
Analyzer anal = new
com.shi.lucene.index.SHIAnalyser(null,null);
org.apache.lucene.store.Directory tmpidxdirectory
= new org.apache.lucene.store.RAMDirectory();
org.apache.lucene.index.IndexWriter tempindexwriter =
new IndexWriter(tmpidxdirectory, anal, true);
Document doc = new Document();
for(int ifld=0; ifld 9; ifld++)
{
doc.add(new Field(field_+ifld, iThread:
+iThread+ field: +ifld+ +System.currentTimeMillis()+
+misc.getDateString()+ +misc.getDateString2()+
+com.shi.jipmisc.getTimeStamp()+ +misc.getClass()+ +misc.getDebug(),
Store.COMPRESS, Field.Index.UN_TOKENIZED));
}
tempindexwriter.addDocument(doc);
tempindexwriter.optimize();
org.apache.lucene.store.Directory[] idxs = new
org.apache.lucene.store.Directory[1];
idxs[0] = tmpidxdirectory;
//todo: del-call...
this.indexwriter.addIndexes(idxs);
if (this.bWithOptimize)
this.indexwriter.optimize();
}
catch(Throwable e)
{
log(testthread:run\tERR:2(bWithOpti:+bWithOptimize+)(iThread:+iThread+):+e.getMessage()+\n\t+com.shi.jipmisc.stack2string(e),
misc);
}
}
}
public SHILuceneWritingFromThreadsTest()
{
}
public static void main(String[] args)
{
testluceneconcurrency(false);
testluceneconcurrency(true );
}
public static java.util.concurrent.ExecutorService threadpool_optimized
= java.util.concurrent.Executors.newFixedThreadPool(999);
public static
[jira] Reopened: (LUCENE-1399) NullPointerException issue with single IndexWriter instance shared among multiple Thread
[
https://issues.apache.org/jira/browse/LUCENE-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reopened LUCENE-1399:
NullPointerException issue with single IndexWriter instance shared among
multiple Thread
Key: LUCENE-1399
URL: https://issues.apache.org/jira/browse/LUCENE-1399
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.3.2
Environment: Windows XP, JDK 1.6
Reporter: Rudi Quark
Fix For: 2.4
NullPointerException is thrown while indexing within multiple threads but
using one single IndexWriter instance. According to Lucene in Action this
should do: ...a single instance of either class can be shared among multiple
threads, and all calls to its index-modifying methods will be properly
synchronized so that index modifications are executed one after the other.
Following my exception trace:
java.lang.NullPointerException
at
org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:475)
at
org.apache.lucene.index.IndexWriter.commitTransaction(IndexWriter.java:1986)
at org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:2219)
at
com.shi.marketingspy.test.SHILuceneWritingFromThreadsTest$testthread.run(SHILuceneWritingFromThreadsTest.java:48)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Following my test program:
package com.shi.marketingspy.test;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.document.Field.Store;
import org.apache.lucene.index.IndexWriter;
public class SHILuceneWritingFromThreadsTest
{
public static void log(String s, com.shi.jipmisc misc)
{
misc.__Log(s);
}
public static class testthread implements Runnable
{
public org.apache.lucene.index.IndexWriter indexwriter;
public int iThread;
public boolean bWithOptimize;
public com.shi.jipmisc misc;
public testthread(org.apache.lucene.index.IndexWriter
indexwriter, int iThread, boolean bWithOptimize, com.shi.jipmisc misc)
{
this.indexwriter= indexwriter;
this.iThread= iThread;
this.bWithOptimize = bWithOptimize;
this.misc = misc;
}
public void run()
{
try
{
Analyzer anal = new
com.shi.lucene.index.SHIAnalyser(null,null);
org.apache.lucene.store.Directory tmpidxdirectory
= new org.apache.lucene.store.RAMDirectory();
org.apache.lucene.index.IndexWriter tempindexwriter =
new IndexWriter(tmpidxdirectory, anal, true);
Document doc = new Document();
for(int ifld=0; ifld 9; ifld++)
{
doc.add(new Field(field_+ifld, iThread:
+iThread+ field: +ifld+ +System.currentTimeMillis()+
+misc.getDateString()+ +misc.getDateString2()+
+com.shi.jipmisc.getTimeStamp()+ +misc.getClass()+ +misc.getDebug(),
Store.COMPRESS, Field.Index.UN_TOKENIZED));
}
tempindexwriter.addDocument(doc);
tempindexwriter.optimize();
org.apache.lucene.store.Directory[] idxs = new
org.apache.lucene.store.Directory[1];
idxs[0] = tmpidxdirectory;
//todo: del-call...
this.indexwriter.addIndexes(idxs);
if (this.bWithOptimize)
this.indexwriter.optimize();
}
catch(Throwable e)
{
log(testthread:run\tERR:2(bWithOpti:+bWithOptimize+)(iThread:+iThread+):+e.getMessage()+\n\t+com.shi.jipmisc.stack2string(e),
misc);
}
}
}
public SHILuceneWritingFromThreadsTest()
{
}
public static void main(String[] args)
{
testluceneconcurrency(false);
testluceneconcurrency(true );
}
public static java.util.concurrent.ExecutorService threadpool_optimized
= java.util.concurrent.Executors.newFixedThreadPool(999);
public static java.util.concurrent.ExecutorService
threadpool_not_optimized =
[jira] Commented: (LUCENE-1393) Lucene's nightly Hudson builds don't have svn version in MANIFEST.MF
[ https://issues.apache.org/jira/browse/LUCENE-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633656#action_12633656 ] Michael McCandless commented on LUCENE-1393: Indeed this is fixed; we once again have the svnversion in the Lucene JAR manifest. Lucene's nightly Hudson builds don't have svn version in MANIFEST.MF Key: LUCENE-1393 URL: https://issues.apache.org/jira/browse/LUCENE-1393 Project: Lucene - Java Issue Type: Bug Components: Build Reporter: Michael McCandless Assignee: Hoss Man Priority: Minor Fix For: 2.9 Solr had the same issue but apparently made a configuration change to the Hudson configuration to get it working: https://issues.apache.org/jira/browse/SOLR-684 Also I opened this INFRA issue: https://issues.apache.org/jira/browse/INFRA-1721 which says the svnversion exe is located in this path: /opt/subversion-current/bin In that INRA issue, /etc/init.d/tomcat was also fixed in theory so that svnversion would be on the path the next time Hudson is restarted. Still, in case that doesn't work, or it changes in the future, it seems a good idea to make the same change that Solr made to Lucene's Hudson configuration. Hoss can you detail what you needed to do for Solr? Or maybe just do it also for Lucene ;) Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-1401) Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false
Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false --- Key: LUCENE-1401 URL: https://issues.apache.org/jira/browse/LUCENE-1401 Project: Lucene - Java Issue Type: Bug Components: Index Affects Versions: 2.4 Reporter: Uwe Schindler Priority: Trivial I am currently changing my code to be most compatible with 2.4. I switched on deprecation warnings and got a warning about the autoCommit parameter in IndexWriter constructors. My code *should* use autoCommit=false, so I want to use the new semantics. The default of IndexWriter is still autoCommit=true. My problem now: How to disable autoCommit whithout deprecation warnings? Maybe, the old constructors, that are deprecated should use autoCommit=true. But there are new constructors with this IndexWriter.MaxFieldLength mfl in it, that appear new in 2.4 but are deprecated: IndexWriter(Directory d, boolean autoCommit, Analyzer a, boolean create, IndexDeletionPolicy deletionPolicy, IndexWriter.MaxFieldLength mfl) Deprecated. This will be removed in 3.0, when autoCommit will be hardwired to false. Use IndexWriter(Directory,Analyzer,boolean,IndexDeletionPolicy,MaxFieldLength) instead, and call commit() when needed. What the hell is meant by this, a new constructor that is deprecated? And the hint is wrong. If I use the other constructor in the warning, I get autoCommit=true. There is something completely wrong. It should be clear, which constructors set autoCommit=true, which set it per default to false (perhaps new ones), and the Deprecated text is wrong, if autoCommit does not default to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1401) Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false
[ https://issues.apache.org/jira/browse/LUCENE-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1401: --- Affects Version/s: 2.9 Fix Version/s: 2.9 2.4 Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false --- Key: LUCENE-1401 URL: https://issues.apache.org/jira/browse/LUCENE-1401 Project: Lucene - Java Issue Type: Bug Components: Index Affects Versions: 2.4, 2.9 Reporter: Uwe Schindler Assignee: Michael McCandless Priority: Trivial Fix For: 2.4, 2.9 I am currently changing my code to be most compatible with 2.4. I switched on deprecation warnings and got a warning about the autoCommit parameter in IndexWriter constructors. My code *should* use autoCommit=false, so I want to use the new semantics. The default of IndexWriter is still autoCommit=true. My problem now: How to disable autoCommit whithout deprecation warnings? Maybe, the old constructors, that are deprecated should use autoCommit=true. But there are new constructors with this IndexWriter.MaxFieldLength mfl in it, that appear new in 2.4 but are deprecated: IndexWriter(Directory d, boolean autoCommit, Analyzer a, boolean create, IndexDeletionPolicy deletionPolicy, IndexWriter.MaxFieldLength mfl) Deprecated. This will be removed in 3.0, when autoCommit will be hardwired to false. Use IndexWriter(Directory,Analyzer,boolean,IndexDeletionPolicy,MaxFieldLength) instead, and call commit() when needed. What the hell is meant by this, a new constructor that is deprecated? And the hint is wrong. If I use the other constructor in the warning, I get autoCommit=true. There is something completely wrong. It should be clear, which constructors set autoCommit=true, which set it per default to false (perhaps new ones), and the Deprecated text is wrong, if autoCommit does not default to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (LUCENE-1401) Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false
[ https://issues.apache.org/jira/browse/LUCENE-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-1401: -- Assignee: Michael McCandless Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false --- Key: LUCENE-1401 URL: https://issues.apache.org/jira/browse/LUCENE-1401 Project: Lucene - Java Issue Type: Bug Components: Index Affects Versions: 2.4, 2.9 Reporter: Uwe Schindler Assignee: Michael McCandless Priority: Trivial Fix For: 2.4, 2.9 I am currently changing my code to be most compatible with 2.4. I switched on deprecation warnings and got a warning about the autoCommit parameter in IndexWriter constructors. My code *should* use autoCommit=false, so I want to use the new semantics. The default of IndexWriter is still autoCommit=true. My problem now: How to disable autoCommit whithout deprecation warnings? Maybe, the old constructors, that are deprecated should use autoCommit=true. But there are new constructors with this IndexWriter.MaxFieldLength mfl in it, that appear new in 2.4 but are deprecated: IndexWriter(Directory d, boolean autoCommit, Analyzer a, boolean create, IndexDeletionPolicy deletionPolicy, IndexWriter.MaxFieldLength mfl) Deprecated. This will be removed in 3.0, when autoCommit will be hardwired to false. Use IndexWriter(Directory,Analyzer,boolean,IndexDeletionPolicy,MaxFieldLength) instead, and call commit() when needed. What the hell is meant by this, a new constructor that is deprecated? And the hint is wrong. If I use the other constructor in the warning, I get autoCommit=true. There is something completely wrong. It should be clear, which constructors set autoCommit=true, which set it per default to false (perhaps new ones), and the Deprecated text is wrong, if autoCommit does not default to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-1401) Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false
[ https://issues.apache.org/jira/browse/LUCENE-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633662#action_12633662 ] Michael McCandless commented on LUCENE-1401: Achieving the migration from autoCommit=true to autoCommit=false is somewhat tricky. As things stand now, all ctors that don't take autoCommit param still default autoCommit to true. Maybe we could flip the autoCommit default to false, now, with the new ctors (the ones that take a MaxFieldLength). This may be better since you have to explicitly update your code, anyway, to switch to IndexWriter's new ctors and so if we call this change out in the javadocs, users are more likely to catch it. Whereas if we suddenly flip the default for autoCommit to false in 3.0, since there's no API signature change, users may not realize this had happened. OK I like that approach better. Are there any objections? bq. But there are new constructors with this IndexWriter.MaxFieldLength mfl in it, that appear new in 2.4 but are deprecated I agree: we should not introduce new deprecated ctors. I'll eliminate these. This happened because there were two separate changes (addition of MaxFieldLength, and, deprecation of autoCommit). Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false --- Key: LUCENE-1401 URL: https://issues.apache.org/jira/browse/LUCENE-1401 Project: Lucene - Java Issue Type: Bug Components: Index Affects Versions: 2.4, 2.9 Reporter: Uwe Schindler Priority: Trivial Fix For: 2.4, 2.9 I am currently changing my code to be most compatible with 2.4. I switched on deprecation warnings and got a warning about the autoCommit parameter in IndexWriter constructors. My code *should* use autoCommit=false, so I want to use the new semantics. The default of IndexWriter is still autoCommit=true. My problem now: How to disable autoCommit whithout deprecation warnings? Maybe, the old constructors, that are deprecated should use autoCommit=true. But there are new constructors with this IndexWriter.MaxFieldLength mfl in it, that appear new in 2.4 but are deprecated: IndexWriter(Directory d, boolean autoCommit, Analyzer a, boolean create, IndexDeletionPolicy deletionPolicy, IndexWriter.MaxFieldLength mfl) Deprecated. This will be removed in 3.0, when autoCommit will be hardwired to false. Use IndexWriter(Directory,Analyzer,boolean,IndexDeletionPolicy,MaxFieldLength) instead, and call commit() when needed. What the hell is meant by this, a new constructor that is deprecated? And the hint is wrong. If I use the other constructor in the warning, I get autoCommit=true. There is something completely wrong. It should be clear, which constructors set autoCommit=true, which set it per default to false (perhaps new ones), and the Deprecated text is wrong, if autoCommit does not default to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Field search without Multifieldqueryparser
Here is what I'm trying to do: say a lucene document: name: abc ^10 organization: xyz ^3 ^10 and ^3 are boosts in the document. now if I query name: abc ^5 AND organization: xyz this will work. but if I query (default_field): abc^5 AND xyz this won't work. Now what I want is that a text can be associated with more than one field. i.e. (field1,field2,field3):value name,(default_field),title: abc^10 organization,(default_field),institute: xyz^3 then both of my queries will work. Is it possible to do so in lucene without changing the source? If no then can anyone please explain the indexing and searching mechanism for lucene, so that I can start working on it. The solution given by the java-users won't work for me as I do not want to add all the contents of the document in a single field and then search for that field, as this would increase the index size and I've to index more than 10 million documents. Also multifieldqueryparser will make it query execution inefficient, as there will be thousands of fields. On Mon, Sep 22, 2008 at 4:06 PM, Grant Ingersoll [EMAIL PROTECTED] wrote: Not sure what you are planning to develop. Can you elaborate? On Sep 21, 2008, at 2:08 PM, Anshul jain wrote: Hi Ryan, Apparently it's not because as far as I know Lucene doesn't support this function and I am planning to develop it. Anshul On Sun, Sep 21, 2008 at 8:04 PM, Ryan McKinley [EMAIL PROTECTED] wrote: Now I can have two types of queries: Structured query: name: George Bush AND Occupation: President please don't remind us! try asking this question on the [EMAIL PROTECTED] that list is for usage related questions ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Anshul Jain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Anshul Jain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1402:
--
Fix Version/s: (was: 2.4)
Affects Version/s: 2.4
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Priority: Minor
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Reporter: Uwe Schindler
Priority: Minor
Fix For: 2.4
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean doFix)
throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1380) Patch for ShingleFilter.enablePositions
[ https://issues.apache.org/jira/browse/LUCENE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mck SembWever updated LUCENE-1380: -- Attachment: LUCENE-1380-PositionFilter.patch If you really want to do this change is this layer I suggest that you seperate out this feature to a new filter that modify the position increment. Attaching alternative patch as suggested for PositionFilter and its test. The first token always maintains its original positionIncrement, but subsequent tokens in the TokenStream has their positionIncrement set to match the value of PositionFilter.positionIncrement I still fail to understand why Karl and Steve would rather see this logic in the QueryParser. The best explanation so far was from Steve: IMO, the correct layer to solve this is in Solr's QParser - I think there should be a way to tell the parser not to parse, but rather to send the whole query to be analyzed. but i wouldn't be surprised if this goes against the grain of how Solr works. Patch for ShingleFilter.enablePositions --- Key: LUCENE-1380 URL: https://issues.apache.org/jira/browse/LUCENE-1380 Project: Lucene - Java Issue Type: Improvement Components: contrib/analyzers Reporter: Mck SembWever Priority: Trivial Attachments: LUCENE-1380-PositionFilter.patch, LUCENE-1380.patch, LUCENE-1380.patch Make it possible for *all* words and shingles to be placed at the same position, that is for _all_ shingles (and unigrams if included) to be treated as synonyms of each other. Today the shingles generated are synonyms only to the first term in the shingle. For example the query abcd efgh ijkl results in: (abcd abcd efgh abcd efgh ijkl) (efgh efgh ijkl) (ijkl) where abcd efgh and abcd efgh ijkl are synonyms of abcd, and efgh ijkl is a synonym of efgh. There exists no way today to alter which token a particular shingle is a synonym for. This patch takes the first step in making it possible to make all shingles (and unigrams if included) synonyms of each other. See http://comments.gmane.org/gmane.comp.jakarta.lucene.user/34746 for mailing list thread. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1380) Patch for ShingleFilter.enablePositions (or PositionFilter)
[ https://issues.apache.org/jira/browse/LUCENE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mck SembWever updated LUCENE-1380: -- Lucene Fields: [New, Patch Available] (was: [Patch Available, New]) Summary: Patch for ShingleFilter.enablePositions (or PositionFilter) (was: Patch for ShingleFilter.enablePositions) Patch for ShingleFilter.enablePositions (or PositionFilter) --- Key: LUCENE-1380 URL: https://issues.apache.org/jira/browse/LUCENE-1380 Project: Lucene - Java Issue Type: Improvement Components: contrib/analyzers Reporter: Mck SembWever Priority: Trivial Attachments: LUCENE-1380-PositionFilter.patch, LUCENE-1380.patch, LUCENE-1380.patch Make it possible for *all* words and shingles to be placed at the same position, that is for _all_ shingles (and unigrams if included) to be treated as synonyms of each other. Today the shingles generated are synonyms only to the first term in the shingle. For example the query abcd efgh ijkl results in: (abcd abcd efgh abcd efgh ijkl) (efgh efgh ijkl) (ijkl) where abcd efgh and abcd efgh ijkl are synonyms of abcd, and efgh ijkl is a synonym of efgh. There exists no way today to alter which token a particular shingle is a synonym for. This patch takes the first step in making it possible to make all shingles (and unigrams if included) synonyms of each other. See http://comments.gmane.org/gmane.comp.jakarta.lucene.user/34746 for mailing list thread. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-1380) Patch for ShingleFilter.enablePositions (or PositionFilter)
[
https://issues.apache.org/jira/browse/LUCENE-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633756#action_12633756
]
Steven Rowe commented on LUCENE-1380:
-
A couple of comments on the PositionFilter patch:
# The javadocs should be more explicit, e.g. about the fact that
positionIncrement defaults to zero
# I think there ought to be a constructor that takes in a positionIncrement,
perhaps instead of the setter.
# You don't handle the case where the filter is used for more than one
document; there should be an else clause that resets firstTokenPositioned to
false after this block:
{code:java}
if(null != reusableToken){
if(firstTokenPositioned){
reusableToken.setPositionIncrement(positionIncrement);
}else{
firstTokenPositioned = true;
}
}
{code}
# You should provide a standalone test for the PositionFilter, in addition to
the ShingleFilterTest tests.
Patch for ShingleFilter.enablePositions (or PositionFilter)
---
Key: LUCENE-1380
URL: https://issues.apache.org/jira/browse/LUCENE-1380
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/analyzers
Reporter: Mck SembWever
Priority: Trivial
Attachments: LUCENE-1380-PositionFilter.patch, LUCENE-1380.patch,
LUCENE-1380.patch
Make it possible for *all* words and shingles to be placed at the same
position, that is for _all_ shingles (and unigrams if included) to be treated
as synonyms of each other.
Today the shingles generated are synonyms only to the first term in the
shingle.
For example the query abcd efgh ijkl results in:
(abcd abcd efgh abcd efgh ijkl) (efgh efgh ijkl) (ijkl)
where abcd efgh and abcd efgh ijkl are synonyms of abcd, and efgh
ijkl is a synonym of efgh.
There exists no way today to alter which token a particular shingle is a
synonym for.
This patch takes the first step in making it possible to make all shingles
(and unigrams if included) synonyms of each other.
See http://comments.gmane.org/gmane.comp.jakarta.lucene.user/34746 for
mailing list thread.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Could positions/payloads in SegmentMerger be copied directly?
Op Tuesday 23 September 2008 10:56:04 schreef Michael McCandless: Paul Elschot wrote: I had another look at SegmentTermDocs.skipTo() and at SegmentTermPositions, and I think I'm beginning to get your point. Could it be doable per skipInterval docs? Almost ... but not quite, except maybe for the first segment being merged. The problem is, the new skip data will not in general be aligned to the old skip data, except for the first segment. EG the skipInterval is 16; say for term foo the first segment has 18 docs and the 2nd segment has 22 docs. We could bulk-copy that first chunk of 16 docs from the first segment, but then we write another 2 docs and then 14 docs into the 2nd segment we need to write new skip data, so we cannot bulk copy the 2nd segment since then we won't know the byte offset at that 14 doc point. I guess we could entertain allowing skip intervals to not be regular, such that at the boundaries of previously merged segments it's allowed to be different, but that's getting more invasive. We have recently made great strides having merging be a bulk byte-copy operation when possible (eg stored fields term vectors do this now), so I agree it'd be fabulous to get the postings to do bulk byte copy. They are the slowest part of merging now. The frq postings could almost be made appendable, if we stored the last docID in a posting list in the term dictionary. This way we could append, but simply rewrite only the first document of each segment after the first segment to be the delta of its docID and the last docID in the segment before it. But again we'd be in trouble with the skip data. So, adding a document offset from the documents/frequencies into the positions/payloads for each document would allow: - bulk copying of the position/payloads during merging, and - a more efficient implementation of TermPositions.skipTo() in that decoding the positions from the last available skip document to the target of skipTo() could be avoided. Is that correct? That would indeed be invasive. Regards, Paul Elschot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1402:
--
Assignee: Michael McCandless
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633785#action_12633785
]
Michael McCandless commented on LUCENE-1402:
Good point -- I'll restore the old one rename the new one. This happened with
LUCENE-1354.
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1402:
---
Attachment: LUCENE-1402.patch
Attached patch. I plan to commit later today.
I renamed the new methods to checkIndex, deprecated the old ones, and fix their
javadocs.
I also added javadocs for CheckIndexStatus, plus a warning that this API is new
experimental and subject to change.
I also changed thew CheckIndexStatus.newSegments to be package protected, since
its type is SegmentInfos which is not public.
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-1402.patch
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633812#action_12633812
]
Uwe Schindler commented on LUCENE-1402:
---
I did not realize about LUCENE-1354, so I am a little bit late with my
concerns. In my opinion, the way how CheckIndex is implemented, is not the
cleanest obect-oriented way. It looks like a standard console program, what it
was at the beginning, but not like a tool for use in other tools (like startup
or maintenance tasks of Solr or my project panFMP). There is one problem:
We have a *static* variable pointing to the output Stream. As this variable is
static, it is everywhere the same. If I want to create a web application that
checks two indexes and this maybe in parallel (because two users started the
check index task), I cannot redirect the output stream to an individual
console (e.g. the servlet output stream).
In my opinion, to be a handy tool, there should be some minor changes:
- the class should have an public constructor getting the Directory
- a public method to set the output stream for the instance (like IndexWriter
does with setInfoStream())
- the check/fix methods as instance methods
The main() method (which must stay static, which is clear) and the two static
and deprecated methods, should instantiate an CheckIndex instance and call the
methods using System.err
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-1402.patch
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633814#action_12633814
]
Uwe Schindler commented on LUCENE-1402:
---
In principle, by making each Checkindex an instance, you would also not need
the CheckIndexStatus class, the variables could be members of CheckIndex, the
usage would be:
- instantiate CheckIndex with Directory
- boolean ok=check
- if (!ok) fix()
- close checkindex instance
For backwards compatibility, the main() and two static methods could do exactly
this. For more detailed status info, look into instance variables.
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-1402.patch
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633821#action_12633821
]
Uwe Schindler commented on LUCENE-1402:
---
And I found a bug in CheckIndex.checkIndex(): the boolean parameter fix is
not used, you must always manually call fix() after checking, so this parameter
is useless!
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-1402.patch
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-1403) StandardTokenizer - Improper Hostname Recognition
StandardTokenizer - Improper Hostname Recognition - Key: LUCENE-1403 URL: https://issues.apache.org/jira/browse/LUCENE-1403 Project: Lucene - Java Issue Type: Bug Affects Versions: 2.3.2, 2.3.1 Environment: Java 5 Reporter: Cullin Wible As of 2.3.1 the documentation for the StandardTokenizer states that it Recognizes email addresses and internet hostnames as one token. However hostnames such as my-host.com are recognized as two tokens my and host.com. Any host with a dash in the name is not recognized properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Could positions/payloads in SegmentMerger be copied directly?
Paul Elschot wrote: So, adding a document offset from the documents/frequencies into the positions/payloads for each document would allow: - bulk copying of the position/payloads during merging, and - a more efficient implementation of TermPositions.skipTo() in that decoding the positions from the last available skip document to the target of skipTo() could be avoided. Is that correct? Yes, though this would also add cost of computing/writing/reading that new offset, and would increase the index size. That would indeed be invasive. Yes. I think our time would likely be better spent working on using PForDelta for freq/prox. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633840#action_12633840
]
Michael McCandless commented on LUCENE-1402:
Good comments all around Uwe; I'll work out a new patch! Thanks.
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-1402.patch
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1402:
--
Attachment: LUCENE-1402-uwe.patch
I hope you did not start to do a patch. I created one, that contains all the
comments and fixes also some bugs:
- the parameter fix in static method remove
- if infoStream/out==null NPE's at different positions
It is not completely tested, but it compiles correct and works for me (using
the API, not main()).
So it needs intensive testing, but should be OK.
Maybe rename method fix() to fixIndex() in comparison to checkIndex().
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-1402-uwe.patch, LUCENE-1402.patch
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-1404) NPE in NearSpansUnordered.isPayloadAvailable()
NPE in NearSpansUnordered.isPayloadAvailable()
---
Key: LUCENE-1404
URL: https://issues.apache.org/jira/browse/LUCENE-1404
Project: Lucene - Java
Issue Type: Bug
Components: Query/Scoring
Affects Versions: 2.4
Reporter: Tim Smith
Using RC1 of lucene 2.4 resulted in null pointer exception with some
constructed SpanNearQueries
Implementation of isPayloadAvailable() (results in exception)
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
do {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
} while(pointer.next != null);
return false;
}
{code}
Fixed isPayloadAvailable()
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
while (pointer != null) {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
}
return false;
}
{code}
Exception produced:
{code}
[junit] java.lang.NullPointerException
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered$SpansCell.access$300(NearSpansUnordered.java:65)
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered.isPayloadAvailable(NearSpansUnordered.java:235)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.shrinkToAfterShortestMatch(NearSpansOrdered.java:246)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.advanceAfterOrdered(NearSpansOrdered.java:154)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.next(NearSpansOrdered.java:122)
[junit] at
org.apache.lucene.search.spans.SpanScorer.next(SpanScorer.java:54)
[junit] at org.apache.lucene.search.Scorer.score(Scorer.java:57)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:137)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:113)
[junit] at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:113)
[junit] at org.apache.lucene.search.Hits.init(Hits.java:80)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:50)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:40)
[junit] at
com.attivio.lucene.SpanQueryTest.search(SpanQueryTest.java:79)
[junit] at
com.attivio.lucene.SpanQueryTest.assertHitCount(SpanQueryTest.java:75)
[junit] at com.attivio.lucene.SpanQueryTest.test(SpanQueryTest.java:67)
{code}
will attach unit test that causes exception (and passes with updated
isPayloadAvailable())
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1404) NPE in NearSpansUnordered.isPayloadAvailable()
[
https://issues.apache.org/jira/browse/LUCENE-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Smith updated LUCENE-1404:
--
Attachment: SpanQueryTest.java
unit test that causes exception attached
NPE in NearSpansUnordered.isPayloadAvailable()
---
Key: LUCENE-1404
URL: https://issues.apache.org/jira/browse/LUCENE-1404
Project: Lucene - Java
Issue Type: Bug
Components: Query/Scoring
Affects Versions: 2.4
Reporter: Tim Smith
Attachments: SpanQueryTest.java
Using RC1 of lucene 2.4 resulted in null pointer exception with some
constructed SpanNearQueries
Implementation of isPayloadAvailable() (results in exception)
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
do {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
} while(pointer.next != null);
return false;
}
{code}
Fixed isPayloadAvailable()
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
while (pointer != null) {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
}
return false;
}
{code}
Exception produced:
{code}
[junit] java.lang.NullPointerException
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered$SpansCell.access$300(NearSpansUnordered.java:65)
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered.isPayloadAvailable(NearSpansUnordered.java:235)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.shrinkToAfterShortestMatch(NearSpansOrdered.java:246)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.advanceAfterOrdered(NearSpansOrdered.java:154)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.next(NearSpansOrdered.java:122)
[junit] at
org.apache.lucene.search.spans.SpanScorer.next(SpanScorer.java:54)
[junit] at org.apache.lucene.search.Scorer.score(Scorer.java:57)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:137)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:113)
[junit] at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:113)
[junit] at org.apache.lucene.search.Hits.init(Hits.java:80)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:50)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:40)
[junit] at
com.attivio.lucene.SpanQueryTest.search(SpanQueryTest.java:79)
[junit] at
com.attivio.lucene.SpanQueryTest.assertHitCount(SpanQueryTest.java:75)
[junit] at
com.attivio.lucene.SpanQueryTest.test(SpanQueryTest.java:67)
{code}
will attach unit test that causes exception (and passes with updated
isPayloadAvailable())
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633858#action_12633858
]
Michael McCandless commented on LUCENE-1402:
Thanks Uwe. I'll merge yours with mine and post a new one.
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-1402-uwe.patch, LUCENE-1402.patch
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Setting Fix Version in JIRA
Hi, When people add new issues to JIRA they most often don't set the Fix Version field. Would it not be better to have a default value for that field, so that new entries don't get forgotten when we filter by Fix Version looking for issues to fix for the next release? If every issue had Fix Version set we'd be able to schedule things better, give reporters and others more insight into when a particular item will be taken care of, etc. When we are ready for the release we'd just bump all unresolved issues to the next planned version (e.g. Solr 1.3.1 or 1.4 or Lucene 2.4 or 2.9) Thoughts? Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1404) NPE in NearSpansUnordered.isPayloadAvailable()
[
https://issues.apache.org/jira/browse/LUCENE-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Smith updated LUCENE-1404:
--
Fix Version/s: 2.4
NPE in NearSpansUnordered.isPayloadAvailable()
---
Key: LUCENE-1404
URL: https://issues.apache.org/jira/browse/LUCENE-1404
Project: Lucene - Java
Issue Type: Bug
Components: Query/Scoring
Affects Versions: 2.4
Reporter: Tim Smith
Fix For: 2.4
Attachments: SpanQueryTest.java
Using RC1 of lucene 2.4 resulted in null pointer exception with some
constructed SpanNearQueries
Implementation of isPayloadAvailable() (results in exception)
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
do {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
} while(pointer.next != null);
return false;
}
{code}
Fixed isPayloadAvailable()
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
while (pointer != null) {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
}
return false;
}
{code}
Exception produced:
{code}
[junit] java.lang.NullPointerException
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered$SpansCell.access$300(NearSpansUnordered.java:65)
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered.isPayloadAvailable(NearSpansUnordered.java:235)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.shrinkToAfterShortestMatch(NearSpansOrdered.java:246)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.advanceAfterOrdered(NearSpansOrdered.java:154)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.next(NearSpansOrdered.java:122)
[junit] at
org.apache.lucene.search.spans.SpanScorer.next(SpanScorer.java:54)
[junit] at org.apache.lucene.search.Scorer.score(Scorer.java:57)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:137)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:113)
[junit] at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:113)
[junit] at org.apache.lucene.search.Hits.init(Hits.java:80)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:50)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:40)
[junit] at
com.attivio.lucene.SpanQueryTest.search(SpanQueryTest.java:79)
[junit] at
com.attivio.lucene.SpanQueryTest.assertHitCount(SpanQueryTest.java:75)
[junit] at
com.attivio.lucene.SpanQueryTest.test(SpanQueryTest.java:67)
{code}
will attach unit test that causes exception (and passes with updated
isPayloadAvailable())
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633851#action_12633851
]
thetaphi edited comment on LUCENE-1402 at 9/23/08 12:38 PM:
-
I hope you did not start to do a patch. I created one, that contains all the
comments and fixes also some bugs:
- the parameter fix in static method remove
- if infoStream/out==null NPE's at different positions
- main() does not set output stream, so main() does not show any messages
It is not completely tested, but it compiles correct and works for me (using
the API, not main()).
So it needs intensive testing, but should be OK.
Maybe rename method fix() to fixIndex() in comparison to checkIndex().
was (Author: thetaphi):
I hope you did not start to do a patch. I created one, that contains all
the comments and fixes also some bugs:
- the parameter fix in static method remove
- if infoStream/out==null NPE's at different positions
It is not completely tested, but it compiles correct and works for me (using
the API, not main()).
So it needs intensive testing, but should be OK.
Maybe rename method fix() to fixIndex() in comparison to checkIndex().
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-1402-uwe.patch, LUCENE-1402.patch
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting Fix Version in JIRA
I think it makes more sense to leave fix version to committers when they assign them self to the issue. I say this because of the hundreds of open and unreviewed issues that one would have to update in the tracker between each release. 23 sep 2008 kl. 21.33 skrev Otis Gospodnetic: Hi, When people add new issues to JIRA they most often don't set the Fix Version field. Would it not be better to have a default value for that field, so that new entries don't get forgotten when we filter by Fix Version looking for issues to fix for the next release? If every issue had Fix Version set we'd be able to schedule things better, give reporters and others more insight into when a particular item will be taken care of, etc. When we are ready for the release we'd just bump all unresolved issues to the next planned version (e.g. Solr 1.3.1 or 1.4 or Lucene 2.4 or 2.9) Thoughts? Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Could positions/payloads in SegmentMerger be copied directly?
Op Tuesday 23 September 2008 20:26:18 schreef Michael McCandless: Paul Elschot wrote: So, adding a document offset from the documents/frequencies into the positions/payloads for each document would allow: - bulk copying of the position/payloads during merging, and - a more efficient implementation of TermPositions.skipTo() in that decoding the positions from the last available skip document to the target of skipTo() could be avoided. Is that correct? Yes, though this would also add cost of computing/writing/reading that new offset, and would increase the index size. That would indeed be invasive. Yes. I think our time would likely be better spent working on using PForDelta for freq/prox. To change the prox data to PForDelta, it's nice to be have bulk copies on prox working first. That would allow to change the total size of the prox data easily. But it appears to be easier to start with the doc/freq data, add more prox pointers there, and then change the prox data. PForDelta is fundamentally different from the existing index data because an encoded number cannot be accessed on a byte border. I don't know yet how to deal with that in the index data structures. Regards, Paul Elschot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting Fix Version in JIRA
Isn't that update thing something that can be done in a single automated JIRA step? I believe I've seen people do that. Maybe my thinking/work style is different, but I find having to manually setting Fix Version as one extra thing I need to do. I don't necessarily assign things to myself, but I have a relatively good idea whether something should and can go in the next version or not. But maybe I'm in the minority here. :) Anyhow, just a suggestion. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Karl Wettin [EMAIL PROTECTED] To: java-dev@lucene.apache.org Sent: Tuesday, September 23, 2008 4:58:47 PM Subject: Re: Setting Fix Version in JIRA I think it makes more sense to leave fix version to committers when they assign them self to the issue. I say this because of the hundreds of open and unreviewed issues that one would have to update in the tracker between each release. 23 sep 2008 kl. 21.33 skrev Otis Gospodnetic: Hi, When people add new issues to JIRA they most often don't set the Fix Version field. Would it not be better to have a default value for that field, so that new entries don't get forgotten when we filter by Fix Version looking for issues to fix for the next release? If every issue had Fix Version set we'd be able to schedule things better, give reporters and others more insight into when a particular item will be taken care of, etc. When we are ready for the release we'd just bump all unresolved issues to the next planned version (e.g. Solr 1.3.1 or 1.4 or Lucene 2.4 or 2.9) Thoughts? Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1401) Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false
[ https://issues.apache.org/jira/browse/LUCENE-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1401: --- Attachment: LUCENE-1401.patch Attached patch that removes the new deprecated ctors, and sets autoCommit=false for the new ctors (that take MaxFieldLength). The bulk of the patch is fixing all places where we were calling the new deprecated ctors. Deprecation of autoCommit in 2.4 leads to compile problems, when autoCommit should be false --- Key: LUCENE-1401 URL: https://issues.apache.org/jira/browse/LUCENE-1401 Project: Lucene - Java Issue Type: Bug Components: Index Affects Versions: 2.4, 2.9 Reporter: Uwe Schindler Assignee: Michael McCandless Priority: Trivial Fix For: 2.4, 2.9 Attachments: LUCENE-1401.patch I am currently changing my code to be most compatible with 2.4. I switched on deprecation warnings and got a warning about the autoCommit parameter in IndexWriter constructors. My code *should* use autoCommit=false, so I want to use the new semantics. The default of IndexWriter is still autoCommit=true. My problem now: How to disable autoCommit whithout deprecation warnings? Maybe, the old constructors, that are deprecated should use autoCommit=true. But there are new constructors with this IndexWriter.MaxFieldLength mfl in it, that appear new in 2.4 but are deprecated: IndexWriter(Directory d, boolean autoCommit, Analyzer a, boolean create, IndexDeletionPolicy deletionPolicy, IndexWriter.MaxFieldLength mfl) Deprecated. This will be removed in 3.0, when autoCommit will be hardwired to false. Use IndexWriter(Directory,Analyzer,boolean,IndexDeletionPolicy,MaxFieldLength) instead, and call commit() when needed. What the hell is meant by this, a new constructor that is deprecated? And the hint is wrong. If I use the other constructor in the warning, I get autoCommit=true. There is something completely wrong. It should be clear, which constructors set autoCommit=true, which set it per default to false (perhaps new ones), and the Deprecated text is wrong, if autoCommit does not default to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1402) CheckIndex API changed without backwards compaitibility
[
https://issues.apache.org/jira/browse/LUCENE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1402:
---
Attachment: LUCENE-1402.patch
OK I merged the two patches.
Uwe, I prefer to keep CheckIndexStatus as a separate class: I don't like that
after you create a new CheckIndex and before you call checkIndex, all of these
members are undefined. I'd like to keep CheckIndex itself stateless (except
for its infoStream).
Otherwise I think everything is merged!
CheckIndex API changed without backwards compaitibility
---
Key: LUCENE-1402
URL: https://issues.apache.org/jira/browse/LUCENE-1402
Project: Lucene - Java
Issue Type: Bug
Components: Index
Affects Versions: 2.4
Reporter: Uwe Schindler
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-1402-uwe.patch, LUCENE-1402.patch,
LUCENE-1402.patch
The API of CheckIndex changed. The Check function returns a CheckIndexStatus
and not boolean. And JavaDocs notes the boolean return value.
I am not sure if it works, but it would be good to have the check method that
returns boolean available @Deprecated, i.e.
@Deprecated public static CheckIndexStatus check(Directory dir, boolean
doFix) throws IOException {
final CheckIndexStatus stat=this.check(dir,doFix);
return stat.clean;
}
I am not sure, if it can be done with the same method name, but it prevents
drop-in-replacements of Lucene to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (LUCENE-1404) NPE in NearSpansUnordered.isPayloadAvailable()
[
https://issues.apache.org/jira/browse/LUCENE-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1404:
--
Assignee: Michael McCandless
NPE in NearSpansUnordered.isPayloadAvailable()
---
Key: LUCENE-1404
URL: https://issues.apache.org/jira/browse/LUCENE-1404
Project: Lucene - Java
Issue Type: Bug
Components: Query/Scoring
Affects Versions: 2.4
Reporter: Tim Smith
Assignee: Michael McCandless
Fix For: 2.4
Attachments: SpanQueryTest.java
Using RC1 of lucene 2.4 resulted in null pointer exception with some
constructed SpanNearQueries
Implementation of isPayloadAvailable() (results in exception)
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
do {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
} while(pointer.next != null);
return false;
}
{code}
Fixed isPayloadAvailable()
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
while (pointer != null) {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
}
return false;
}
{code}
Exception produced:
{code}
[junit] java.lang.NullPointerException
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered$SpansCell.access$300(NearSpansUnordered.java:65)
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered.isPayloadAvailable(NearSpansUnordered.java:235)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.shrinkToAfterShortestMatch(NearSpansOrdered.java:246)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.advanceAfterOrdered(NearSpansOrdered.java:154)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.next(NearSpansOrdered.java:122)
[junit] at
org.apache.lucene.search.spans.SpanScorer.next(SpanScorer.java:54)
[junit] at org.apache.lucene.search.Scorer.score(Scorer.java:57)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:137)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:113)
[junit] at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:113)
[junit] at org.apache.lucene.search.Hits.init(Hits.java:80)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:50)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:40)
[junit] at
com.attivio.lucene.SpanQueryTest.search(SpanQueryTest.java:79)
[junit] at
com.attivio.lucene.SpanQueryTest.assertHitCount(SpanQueryTest.java:75)
[junit] at
com.attivio.lucene.SpanQueryTest.test(SpanQueryTest.java:67)
{code}
will attach unit test that causes exception (and passes with updated
isPayloadAvailable())
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-1404) NPE in NearSpansUnordered.isPayloadAvailable()
[
https://issues.apache.org/jira/browse/LUCENE-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633945#action_12633945
]
Michael McCandless commented on LUCENE-1404:
I can confirm this... I'll commit to 2.4 2.9. Thanks Tim!
NPE in NearSpansUnordered.isPayloadAvailable()
---
Key: LUCENE-1404
URL: https://issues.apache.org/jira/browse/LUCENE-1404
Project: Lucene - Java
Issue Type: Bug
Components: Query/Scoring
Affects Versions: 2.4
Reporter: Tim Smith
Assignee: Michael McCandless
Fix For: 2.4
Attachments: SpanQueryTest.java
Using RC1 of lucene 2.4 resulted in null pointer exception with some
constructed SpanNearQueries
Implementation of isPayloadAvailable() (results in exception)
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
do {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
} while(pointer.next != null);
return false;
}
{code}
Fixed isPayloadAvailable()
{code}
public boolean isPayloadAvailable() {
SpansCell pointer = min();
while (pointer != null) {
if(pointer.isPayloadAvailable()) {
return true;
}
pointer = pointer.next;
}
return false;
}
{code}
Exception produced:
{code}
[junit] java.lang.NullPointerException
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered$SpansCell.access$300(NearSpansUnordered.java:65)
[junit] at
org.apache.lucene.search.spans.NearSpansUnordered.isPayloadAvailable(NearSpansUnordered.java:235)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.shrinkToAfterShortestMatch(NearSpansOrdered.java:246)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.advanceAfterOrdered(NearSpansOrdered.java:154)
[junit] at
org.apache.lucene.search.spans.NearSpansOrdered.next(NearSpansOrdered.java:122)
[junit] at
org.apache.lucene.search.spans.SpanScorer.next(SpanScorer.java:54)
[junit] at org.apache.lucene.search.Scorer.score(Scorer.java:57)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:137)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:113)
[junit] at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:113)
[junit] at org.apache.lucene.search.Hits.init(Hits.java:80)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:50)
[junit] at org.apache.lucene.search.Searcher.search(Searcher.java:40)
[junit] at
com.attivio.lucene.SpanQueryTest.search(SpanQueryTest.java:79)
[junit] at
com.attivio.lucene.SpanQueryTest.assertHitCount(SpanQueryTest.java:75)
[junit] at
com.attivio.lucene.SpanQueryTest.test(SpanQueryTest.java:67)
{code}
will attach unit test that causes exception (and passes with updated
isPayloadAvailable())
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting Fix Version in JIRA
On 23-Sep-08, at 12:33 PM, Otis Gospodnetic wrote: Hi, When people add new issues to JIRA they most often don't set the Fix Version field. Would it not be better to have a default value for that field, so that new entries don't get forgotten when we filter by Fix Version looking for issues to fix for the next release? If every issue had Fix Version set we'd be able to schedule things better, give reporters and others more insight into when a particular item will be taken care of, etc. When we are ready for the release we'd just bump all unresolved issues to the next planned version (e.g. Solr 1.3.1 or 1.4 or Lucene 2.4 or 2.9) -1 I doesn't make sense to automatically schedule something to be fixed in the next version of the product. I would be +1 on automatically setting the fix version for the current unreleased version when an issue is resolved as fixed, though. -Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
