[jira] [Commented] (LUCENE-3206) FST package API refactoring
[
https://issues.apache.org/jira/browse/LUCENE-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051658#comment-13051658
]
Dawid Weiss commented on LUCENE-3206:
-
I confirmed the above, out of sheer curiosity, by compiling without expanded
nodes (just linear packing).
{noformat}
261,820,296 utf32-noexp.fst
271,461,850 utf32.fst
263,415,558 utf8-noexp.fst
270,137,939 utf8.fst
{noformat}
FST package API refactoring
---
Key: LUCENE-3206
URL: https://issues.apache.org/jira/browse/LUCENE-3206
Project: Lucene - Java
Issue Type: Improvement
Components: core/FSTs
Affects Versions: 3.2
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Minor
Fix For: 3.3, 4.0
Attachments: LUCENE-3206.patch
The current API is still marked @experimental, so I think there's still time
to fiddle with it. I've been using the current API for some time and I do
have some ideas for improvement. This is a placeholder for these -- I'll post
a patch once I have a working proof of concept.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Jenkins Build for flexscoring branch
Hey folks, FYI, I created a Jenkins job for the flexscoring branch which runs the test only every 4h. https://builds.apache.org/job/Lucene-Solr-tests-only-flexscoring-branch/ Simon - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2454) Nested Document query support
[
https://issues.apache.org/jira/browse/LUCENE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051662#comment-13051662
]
Paul Elschot commented on LUCENE-2454:
--
With these rewrite and createWeight methods TestNestedDocumentQuery passes:
{code}
+ @Override
+ public Query rewrite(IndexReader reader) throws IOException {
+Query rewrittenChildQuery = childQuery.rewrite(reader);
+return (rewrittenChildQuery == childQuery) ? this
+ : new NestedDocumentQuery(rewrittenChildQuery, parentsFilter, scoreMode);
+ }
+
+ @Override
+ public Weight createWeight(IndexSearcher searcher) throws IOException {
+return new NestedDocumentQueryWeight(childQuery.createWeight(searcher));
+ }
+
{code}
I'll continue adding the use of prevSetBit.
Would modules/grouping meanwhile be a better place for this than
lucene/contrib/queries?
Nested Document query support
-
Key: LUCENE-2454
URL: https://issues.apache.org/jira/browse/LUCENE-2454
Project: Lucene - Java
Issue Type: New Feature
Components: core/search
Affects Versions: 3.0.2
Reporter: Mark Harwood
Assignee: Mark Harwood
Priority: Minor
Attachments: LUCENE-2454.patch, LuceneNestedDocumentSupport.zip
A facility for querying nested documents in a Lucene index as outlined in
http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2793) Directory createOutput and openInput should take an IOContext
[ https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051665#comment-13051665 ] Simon Willnauer commented on LUCENE-2793: - hey varun thanks for the new patch, some comments: * the nocommit in IW you should maybe add a second ctor to MergeInfo that takes arguments and then use something like this in IW: final IOContext context = new IOContext(new MergeInfo(info.docCount, info.sizeInBytes(true), true, false)); * It seems kind of odd to always prefix MergeInfo with OneMerge so maybe move it into its own file * regarding the read buffer problem, can you simply use BufferedIndexInput.BUFFER_SIZE to initialize it and put a TODO / nocommit on top * You should look into contrib/misc there are some compile errors in AppendingCodec as well as in solr land. * I think in Directory the openInput method should be abstract: public abstract IndexInput openInput(String name, IOContext context) throws IOException; and FSDirectory should not specify this method at all. Currently your code would produce a stack overflow since it calls itself. If I fix the nocommits in your patch test-core passes without problems. Looking good man we are getting closer! Simon Directory createOutput and openInput should take an IOContext - Key: LUCENE-2793 URL: https://issues.apache.org/jira/browse/LUCENE-2793 Project: Lucene - Java Issue Type: Improvement Components: core/store Reporter: Michael McCandless Assignee: Varun Thacker Labels: gsoc2011, lucene-gsoc-11, mentor Attachments: LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch Today for merging we pass down a larger readBufferSize than for searching because we get better performance. I think we should generalize this to a class (IOContext), which would hold the buffer size, but then could hold other flags like DIRECT (bypass OS's buffer cache), SEQUENTIAL, etc. Then, we can make the DirectIOLinuxDirectory fully usable because we would only use DIRECT/SEQUENTIAL during merging. This will require fixing how IW pools readers, so that a reader opened for merging is not then used for searching, and vice/versa. Really, it's only all the open file handles that need to be different -- we could in theory share del docs, norms, etc, if that were somehow possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-flexscoring-branch - Build # 1 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-flexscoring-branch/1/ All tests passed Build Log (for compile errors): [...truncated 16751 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 8901 - Failure
I just committed a fix! The problem was if there was an already-running merge when the optimize is called, we were failing to note the the segment being produced by that merge is eligible for further merging (because it can have carried-over deletes when it finishes, which should also be merged away by the optimize). Phew! Thank your random testing + Jenkins :) Mike McCandless http://blog.mikemccandless.com On Sat, Jun 18, 2011 at 6:14 PM, Robert Muir rcm...@gmail.com wrote: this one was triggered by LUCENE-3197 On Sat, Jun 18, 2011 at 5:59 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/8901/ 1 tests failed. REGRESSION: org.apache.lucene.TestExternalCodecs.testPerFieldCodec Error Message: expected:727 but was:728 Stack Trace: junit.framework.AssertionFailedError: expected:727 but was:728 at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1415) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1333) at org.apache.lucene.TestExternalCodecs.testPerFieldCodec(TestExternalCodecs.java:566) Build Log (for compile errors): [...truncated 3256 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: svn commit: r1137211 - in /lucene/dev/trunk/lucene: ./ contrib/misc/src/java/org/apache/lucene/index/ src/java/org/apache/lucene/index/ src/test-framework/org/apache/lucene/index/ src/test/org/apa
Just for curiosity:
@@ -93,14 +94,16 @@ public class UpgradeIndexMergePolicy ext
if (oldSegments.isEmpty())
return null;
-MergeSpecification spec = base.findMergesForOptimize(segmentInfos,
maxSegmentCount, oldSegments);
+MergeSpecification spec = base.findMergesForOptimize(segmentInfos,
+ maxSegmentCount, oldSegments);
if (spec != null) {
// remove all segments that are in merge specification from
oldSegments,
// the resulting set contains all segments that are left over
// and will be merged to one additional segment:
for (final OneMerge om : spec.merges) {
-oldSegments.removeAll(om.segments);
+for(SegmentInfo info : om.segments) {
+ oldSegments.remove(info);
+}
}
}
This can be simply be optimized by using views:
oldSegments.keySet().removeAll(om.segments);
Uwe
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2608) TestReplicationHandler is flakey
TestReplicationHandler is flakey
Key: SOLR-2608
URL: https://issues.apache.org/jira/browse/SOLR-2608
Project: Solr
Issue Type: Bug
Reporter: selckin
I've been running some while(1) tests on trunk, and TestReplicationHandler is
very flakey it fails about every 10th run.
Probably not a bug, but the test not waiting correctly
{code}
[junit] Testsuite: org.apache.solr.handler.TestReplicationHandler
[junit] Testcase: org.apache.solr.handler.TestReplicationHandler: FAILED
[junit] ERROR: SolrIndexSearcher opens=48 closes=47
[junit] junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher
opens=48 closes=47
[junit] at
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:131)
[junit] at
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:74)
[junit]
[junit]
[junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 40.772 sec
[junit]
[junit] - Standard Error -
[junit] 19-Jun-2011 21:26:44 org.apache.solr.handler.SnapPuller
fetchLatestIndex
[junit] SEVERE: Master at: http://localhost:51817/solr/replication is not
available. Index fetch failed. Exception: Connection refused
[junit] 19-Jun-2011 21:26:49 org.apache.solr.common.SolrException log
[junit] SEVERE: java.util.concurrent.RejectedExecutionException
[junit] at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
[junit] at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
[junit] at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
[junit] at
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92)
[junit] at
java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:603)
[junit] at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1149)
[junit] at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:346)
[junit] at
org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:483)
[junit] at
org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:332)
[junit] at
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:267)
[junit] at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:166)
[junit] at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
[junit] at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
[junit] at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[junit] at java.lang.Thread.run(Thread.java:662)
[junit]
[junit] 19-Jun-2011 21:26:51 org.apache.solr.update.SolrIndexWriter finalize
[junit] SEVERE: SolrIndexWriter was not closed prior to finalize(),
indicates a bug -- POSSIBLE RESOURCE LEAK!!!
[junit] 19-Jun-2011 21:26:51 org.apache.solr.common.util.ConcurrentLRUCache
finalize
[junit] SEVERE: ConcurrentLRUCache was not destroyed prior to finalize(),
indicates a bug -- POSSIBLE RESOURCE LEAK!!!
[junit] 19-Jun-2011 21:27:13 org.apache.solr.handler.SnapPuller
fetchLatestIndex
[junit] SEVERE: Master at: http://localhost:46559/solr/replication is not
available. Index fetch failed. Exception: Connection refused
[junit] 19-Jun-2011 21:27:14 org.apache.solr.handler.SnapPuller
fetchLatestIndex
[junit] SEVERE: Master at: http://localhost:46559/solr/replication is not
available. Index fetch failed. Exception: Connection refused
[junit] 19-Jun-2011 21:27:14 org.apache.solr.SolrTestCaseJ4
endTrackingSearchers
[junit] SEVERE: ERROR: SolrIndexSearcher opens=48 closes=47
[junit] - ---
[junit] TEST org.apache.solr.handler.TestReplicationHandler FAILED
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2454) Nested Document query support
[ https://issues.apache.org/jira/browse/LUCENE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Elschot updated LUCENE-2454: - Attachment: LUCENE-2454.patch Patch of 19 June 2011. In NestedDocumentQuery.java: Added use of prevSetBit with an assert for the presence of a parent. Added/changed rewrite/createWeight. Also added equals/hashCode. TestNestedDocument.java is unchanged in this patch and passes. In the patch both java files are in lucene/contrib/queries. There is still one nocommit for the enum for the score mode. Nested Document query support - Key: LUCENE-2454 URL: https://issues.apache.org/jira/browse/LUCENE-2454 Project: Lucene - Java Issue Type: New Feature Components: core/search Affects Versions: 3.0.2 Reporter: Mark Harwood Assignee: Mark Harwood Priority: Minor Attachments: LUCENE-2454.patch, LUCENE-2454.patch, LuceneNestedDocumentSupport.zip A facility for querying nested documents in a Lucene index as outlined in http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2454) Nested Document query support
[ https://issues.apache.org/jira/browse/LUCENE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051673#comment-13051673 ] Paul Elschot commented on LUCENE-2454: -- The assert on the parent was an IllegalArgumentException in the previous patch. Such and unconditional exception would probably be better than an assert, because when the assert is switched off a mistake in the parent filter would not be detected early. Nested Document query support - Key: LUCENE-2454 URL: https://issues.apache.org/jira/browse/LUCENE-2454 Project: Lucene - Java Issue Type: New Feature Components: core/search Affects Versions: 3.0.2 Reporter: Mark Harwood Assignee: Mark Harwood Priority: Minor Attachments: LUCENE-2454.patch, LUCENE-2454.patch, LuceneNestedDocumentSupport.zip A facility for querying nested documents in a Lucene index as outlined in http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1137211 - in /lucene/dev/trunk/lucene: ./ contrib/misc/src/java/org/apache/lucene/index/ src/java/org/apache/lucene/index/ src/test-framework/org/apache/lucene/index/ src/test/org/apa
Ahh yes, good! I'll fix.
Mike McCandless
http://blog.mikemccandless.com
On Sun, Jun 19, 2011 at 6:39 AM, Uwe Schindler u...@thetaphi.de wrote:
Just for curiosity:
@@ -93,14 +94,16 @@ public class UpgradeIndexMergePolicy ext
if (oldSegments.isEmpty())
return null;
- MergeSpecification spec = base.findMergesForOptimize(segmentInfos,
maxSegmentCount, oldSegments);
+ MergeSpecification spec = base.findMergesForOptimize(segmentInfos,
+ maxSegmentCount, oldSegments);
if (spec != null) {
// remove all segments that are in merge specification from
oldSegments,
// the resulting set contains all segments that are left over
// and will be merged to one additional segment:
for (final OneMerge om : spec.merges) {
- oldSegments.removeAll(om.segments);
+ for(SegmentInfo info : om.segments) {
+ oldSegments.remove(info);
+ }
}
}
This can be simply be optimized by using views:
oldSegments.keySet().removeAll(om.segments);
Uwe
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3206) FST package API refactoring
[ https://issues.apache.org/jira/browse/LUCENE-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051684#comment-13051684 ] Michael McCandless commented on LUCENE-3206: OK, these results make sense! UTF32 (vInt labels) is more compact than UTF8, if you disable array'd arcs. These wiki terms are from the en export right? So the differences are due to the smallish number of random terms that are not English... it should be more extreme if we used non-English content. I wonder how lookup time would compare... I think UTF32 should be faster? And yes for truly binary terms (eg collated fields, and maybe eventually numeric fields but not yet because they still avoid the 8th bit I think) I think we want to keep BYTE1. We need some good use cases of FSTs during analysis... there we are free to make the alphabet non-byte (vs the index, where terms are a BytesRef). FST package API refactoring --- Key: LUCENE-3206 URL: https://issues.apache.org/jira/browse/LUCENE-3206 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Affects Versions: 3.2 Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.3, 4.0 Attachments: LUCENE-3206.patch The current API is still marked @experimental, so I think there's still time to fiddle with it. I've been using the current API for some time and I do have some ideas for improvement. This is a placeholder for these -- I'll post a patch once I have a working proof of concept. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3206) FST package API refactoring
[ https://issues.apache.org/jira/browse/LUCENE-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051688#comment-13051688 ] Uwe Schindler commented on LUCENE-3206: --- Just one question: Is sort order for suppl chars in UTF32 compatible to UTF8 or will there be more problems? As we have a special case for UTF16 (surrogates dance), so what happens with a third encoding? FST package API refactoring --- Key: LUCENE-3206 URL: https://issues.apache.org/jira/browse/LUCENE-3206 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Affects Versions: 3.2 Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.3, 4.0 Attachments: LUCENE-3206.patch The current API is still marked @experimental, so I think there's still time to fiddle with it. I've been using the current API for some time and I do have some ideas for improvement. This is a placeholder for these -- I'll post a patch once I have a working proof of concept. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Error :dataimport handler is not request Handler, help
Hi All , I am really stuck in this problem , I am using solr to index some tables in database and I followed these steps to achieve my goal 1- added the following section to solrconfig.xml requestHandler name=/dataimport class=org.apache.solr.handler.dataimport.DataImportHandler lst name=defaults str name=configdata-config.xml/str /lst /requestHandler *2- added apache-solr-dataimporthandler.jar to lib/ directory (include path) every thing goes nice !!! for now , till I fire the server the following error appears , Please I need You help urgently !!! ===Error message== *HTTP ERROR 500 Problem accessing /solr/. Reason: Severe errors in solr configuration. Check your log files for more detailed information on what may be wrong. - org.apache.solr.common.SolrException: Error Instantiating Request Handler, org.apache.solr.handler.dataimport.DataImportHandler is not a org.apache.solr.request.SolrRequestHandler at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:396) at org.apache.solr.core.SolrCore.createRequestHandler(SolrCore.java:431) at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:158) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:291) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:240) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:93) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985) 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:616) at org.mortbay.start.Main.invokeMain(Main.java:194) at org.mortbay.start.Main.start(Main.java:534) at org.mortbay.start.Main.start(Main.java:441) at org.mortbay.start.Main.main(Main.java:119) - org.apache.solr.common.SolrException: RequestHandler init failure at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:173) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:291) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:240) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:93) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282) at
Re: Error :dataimport handler is not request Handler, help
Add the jar to your classpath or put in solr/lib From: Muhannad muh.a...@gmail.com Reply-To: dev@lucene.apache.org Date: Sun, 19 Jun 2011 21:00:57 +0300 To: dev@lucene.apache.org Subject: Error :dataimport handler is not request Handler, help Hi All , I am really stuck in this problem , I am using solr to index some tables in database and I followed these steps to achieve my goal 1- added the following section to solrconfig.xml requestHandler name=/dataimport class=org.apache.solr.handler.dataimport.DataImportHandler lst name=defaults str name=configdata-config.xml/str /lst /requestHandler 2- added apache-solr-dataimporthandler.jar to lib/ directory (include path) every thing goes nice !!! for now , till I fire the server the following error appears , Please I need You help urgently !!! ===Error message== HTTP ERROR 500 Problem accessing /solr/. Reason: Severe errors in solr configuration. Check your log files for more detailed information on what may be wrong. - org.apache.solr.common.SolrException: Error Instantiating Request Handler, org.apache.solr.handler.dataimport.DataImportHandler is not a org.apache.solr.request.SolrRequestHandler at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:396) at org.apache.solr.core.SolrCore.createRequestHandler(SolrCore.java:431) at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers. java:158) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:291) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java :240) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:93) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:1 52) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCol lection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:1 52) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985) 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:616) at org.mortbay.start.Main.invokeMain(Main.java:194) at org.mortbay.start.Main.start(Main.java:534) at org.mortbay.start.Main.start(Main.java:441) at org.mortbay.start.Main.main(Main.java:119) - org.apache.solr.common.SolrException: RequestHandler init failure at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers. java:173) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:291) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java :240) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:93) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at
Re: Error :dataimport handler is not request Handler, help
I have added this file apache-solr-dataimporthandler-4.0-SNAPSHOT.jar to class path , but the same error is still On Sun, Jun 19, 2011 at 9:27 PM, Bill Bell billnb...@gmail.com wrote: Add the jar to your classpath or put in solr/lib From: Muhannad muh.a...@gmail.com Reply-To: dev@lucene.apache.org Date: Sun, 19 Jun 2011 21:00:57 +0300 To: dev@lucene.apache.org Subject: Error :dataimport handler is not request Handler, help Hi All , I am really stuck in this problem , I am using solr to index some tables in database and I followed these steps to achieve my goal 1- added the following section to solrconfig.xmlrequestHandler name=/dataimport class=org.apache.solr.handler.dataimport.DataImportHandler lst name=defaults str name=configdata-config.xml/str /lst /requestHandler *2- added apache-solr-dataimporthandler.jar to lib/ directory (include path) every thing goes nice !!! for now , till I fire the server the following error appears , Please I need You help urgently !!! ===Error message== * HTTP ERROR 500 Problem accessing /solr/. Reason: Severe errors in solr configuration. Check your log files for more detailed information on what may be wrong. - org.apache.solr.common.SolrException: Error Instantiating Request Handler, org.apache.solr.handler.dataimport.DataImportHandler is not a org.apache.solr.request.SolrRequestHandler at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:396) at org.apache.solr.core.SolrCore.createRequestHandler(SolrCore.java:431) at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:158) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:291) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:240) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:93) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985) 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:616) at org.mortbay.start.Main.invokeMain(Main.java:194) at org.mortbay.start.Main.start(Main.java:534) at org.mortbay.start.Main.start(Main.java:441) at org.mortbay.start.Main.main(Main.java:119) - org.apache.solr.common.SolrException: RequestHandler init failure at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:173) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:291) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:240) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:93) at
[jira] [Updated] (LUCENE-2793) Directory createOutput and openInput should take an IOContext
[ https://issues.apache.org/jira/browse/LUCENE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated LUCENE-2793: -- Attachment: LUCENE-2793.patch Made the changes and I get a Build Successful too ! Directory createOutput and openInput should take an IOContext - Key: LUCENE-2793 URL: https://issues.apache.org/jira/browse/LUCENE-2793 Project: Lucene - Java Issue Type: Improvement Components: core/store Reporter: Michael McCandless Assignee: Varun Thacker Labels: gsoc2011, lucene-gsoc-11, mentor Attachments: LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch, LUCENE-2793.patch Today for merging we pass down a larger readBufferSize than for searching because we get better performance. I think we should generalize this to a class (IOContext), which would hold the buffer size, but then could hold other flags like DIRECT (bypass OS's buffer cache), SEQUENTIAL, etc. Then, we can make the DirectIOLinuxDirectory fully usable because we would only use DIRECT/SEQUENTIAL during merging. This will require fixing how IW pools readers, so that a reader opened for merging is not then used for searching, and vice/versa. Really, it's only all the open file handles that need to be different -- we could in theory share del docs, norms, etc, if that were somehow possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3206) FST package API refactoring
[ https://issues.apache.org/jira/browse/LUCENE-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051725#comment-13051725 ] Dawid Weiss commented on LUCENE-3206: - UTF32 is basically codepoint representation, so there are no surrogates (as in UTF16) and there is no special encoding of higher codepoints (as in UTF8). I don't know what sort order is used inside Lucene (is it UTF8 byte-to-byte values or decoded codepoints?). If it is codepoint order then no problem -- this should be preserved. I'll stick to BYTE1/BYTE4 inputs then for now and I'll try to push this patch forward in my spare time. FST package API refactoring --- Key: LUCENE-3206 URL: https://issues.apache.org/jira/browse/LUCENE-3206 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Affects Versions: 3.2 Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.3, 4.0 Attachments: LUCENE-3206.patch The current API is still marked @experimental, so I think there's still time to fiddle with it. I've been using the current API for some time and I do have some ideas for improvement. This is a placeholder for these -- I'll post a patch once I have a working proof of concept. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3206) FST package API refactoring
[ https://issues.apache.org/jira/browse/LUCENE-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051728#comment-13051728 ] Uwe Schindler commented on LUCENE-3206: --- The term index is sorted by utf8 bytes natively. So a FST build on term index must assume that order, because the terms must be presorted for Builder. Lucene internally only works on byte[] and uses per default this order. Also most queries rely on it. FST package API refactoring --- Key: LUCENE-3206 URL: https://issues.apache.org/jira/browse/LUCENE-3206 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Affects Versions: 3.2 Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.3, 4.0 Attachments: LUCENE-3206.patch The current API is still marked @experimental, so I think there's still time to fiddle with it. I've been using the current API for some time and I do have some ideas for improvement. This is a placeholder for these -- I'll post a patch once I have a working proof of concept. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Error :dataimport handler is not request Handler, help
I have tried many things , same problem still , any help? On Sun, Jun 19, 2011 at 9:00 PM, Muhannad muh.a...@gmail.com wrote: Hi All , I am really stuck in this problem , I am using solr to index some tables in database and I followed these steps to achieve my goal 1- added the following section to solrconfig.xmlrequestHandler name=/dataimport class=org.apache.solr.handler.dataimport.DataImportHandler lst name=defaults str name=configdata-config.xml/str /lst /requestHandler *2- added apache-solr-dataimporthandler.jar to lib/ directory (include path) every thing goes nice !!! for now , till I fire the server the following error appears , Please I need You help urgently !!! ===Error message== * HTTP ERROR 500 Problem accessing /solr/. Reason: Severe errors in solr configuration. Check your log files for more detailed information on what may be wrong. - org.apache.solr.common.SolrException: Error Instantiating Request Handler, org.apache.solr.handler.dataimport.DataImportHandler is not a org.apache.solr.request.SolrRequestHandler at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:396) at org.apache.solr.core.SolrCore.createRequestHandler(SolrCore.java:431) at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:158) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:291) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:240) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:93) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985) 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:616) at org.mortbay.start.Main.invokeMain(Main.java:194) at org.mortbay.start.Main.start(Main.java:534) at org.mortbay.start.Main.start(Main.java:441) at org.mortbay.start.Main.main(Main.java:119) - org.apache.solr.common.SolrException: RequestHandler init failure at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:173) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:291) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:240) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:93) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 8926 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/8926/ 1 tests failed. REGRESSION: org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability Error Message: Error executing query Stack Trace: org.apache.solr.client.solrj.SolrServerException: Error executing query at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:95) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:119) at org.apache.solr.client.solrj.TestLBHttpSolrServer.waitForServer(TestLBHttpSolrServer.java:189) at org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability(TestLBHttpSolrServer.java:182) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1415) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1333) Caused by: org.apache.solr.common.SolrException: parsing error at org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(BinaryResponseParser.java:43) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:477) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:395) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:89) Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:146) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at org.apache.commons.httpclient.ContentLengthInputStream.read(ContentLengthInputStream.java:170) at java.io.FilterInputStream.read(FilterInputStream.java:133) at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java:108) at org.apache.solr.common.util.FastInputStream.refill(FastInputStream.java:68) at org.apache.solr.common.util.FastInputStream.readByte(FastInputStream.java:159) at org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:97) at org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(BinaryResponseParser.java:41) Build Log (for compile errors): [...truncated 8545 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Error :dataimport handler is not request Handler, help
Did you try adding something like this to solrconfig.xml ? lib dir=../../../../dist/ regex=apache-solr-dataimporthandler-.*\.jar / requestHandler name=/dataimport class=org.apache.solr.handler.dataimport.DataImportHandler lst name=defaults str name=configdb-data-config.xml/str /lst /requestHandler From: Muhannad muh.a...@gmail.com Reply-To: dev@lucene.apache.org Date: Sun, 19 Jun 2011 23:42:45 +0300 To: dev@lucene.apache.org Subject: Re: Error :dataimport handler is not request Handler, help I have tried many things , same problem still , any help? On Sun, Jun 19, 2011 at 9:00 PM, Muhannad muh.a...@gmail.com wrote: Hi All , I am really stuck in this problem , I am using solr to index some tables in database and I followed these steps to achieve my goal 1- added the following section to solrconfig.xml requestHandler name=/dataimport class=org.apache.solr.handler.dataimport.DataImportHandler lst name=defaults str name=configdata-config.xml/str /lst /requestHandler 2- added apache-solr-dataimporthandler.jar to lib/ directory (include path) every thing goes nice !!! for now , till I fire the server the following error appears , Please I need You help urgently !!! ===Error message== HTTP ERROR 500 Problem accessing /solr/. Reason: Severe errors in solr configuration. Check your log files for more detailed information on what may be wrong. - org.apache.solr.common.SolrException: Error Instantiating Request Handler, org.apache.solr.handler.dataimport.DataImportHandler is not a org.apache.solr.request.SolrRequestHandler at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:396) at org.apache.solr.core.SolrCore.createRequestHandler(SolrCore.java:431) at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.ja va:158) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:291) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:2 40) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:93) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152 ) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerColle ction.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152 ) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.j ava:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.mortbay.start.Main.invokeMain(Main.java:194) at org.mortbay.start.Main.start(Main.java:534) at org.mortbay.start.Main.start(Main.java:441) at org.mortbay.start.Main.main(Main.java:119) - org.apache.solr.common.SolrException: RequestHandler init failure at org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.ja va:173) at org.apache.solr.core.SolrCore.init(SolrCore.java:513) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:653) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:406) at
[jira] [Commented] (SOLR-2524) Adding grouping to Solr 3x
[ https://issues.apache.org/jira/browse/SOLR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051747#comment-13051747 ] Bill Bell commented on SOLR-2524: - Question: Does this support the option of getting facet counts after grouping? I am getting lost in all the issues Thank you... Adding grouping to Solr 3x -- Key: SOLR-2524 URL: https://issues.apache.org/jira/browse/SOLR-2524 Project: Solr Issue Type: New Feature Reporter: Martijn van Groningen Assignee: Martijn van Groningen Fix For: 3.3 Attachments: SOLR-2524.patch, SOLR-2524.patch, SOLR-2524.patch, SOLR-2524.patch, SOLR-2524.patch, SOLR-2524.patch Grouping was recently added to Lucene 3x. See LUCENE-1421 for more information. I think it would be nice if we expose this functionality also to the Solr users that are bound to a 3.x version. The grouping feature added to Lucene is currently a subset of the functionality that Solr 4.0-trunk offers. Mainly it doesn't support grouping by function / query. The work involved getting the grouping contrib to work on Solr 3x is acceptable. I have it more or less running here. It supports the response format and request parameters (expect: group.query and group.func) described in the FieldCollapse page on the Solr wiki. I think it would be great if this is included in the Solr 3.2 release. Many people are using grouping as patch now and this would help them a lot. Any thoughts? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-219) Determine if prefix, wildcard, fuzzy queries should be lowercased
[ https://issues.apache.org/jira/browse/SOLR-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051752#comment-13051752 ] Robert Muir commented on SOLR-219: -- Mike I don't totally understand the question: in general there are only several categories of queries supported by the queryparser: * Core queries like Term, Phrase, SloppyPhrase, MultiPhrase: these go thru the analyzer. * MultiTermQueries like WildcardQuery, PrefixQuery, FuzzyQuery, RegexpQuery, which are patterns that rewrite against the term index into some simpler form (e.g. into TermQueries) If you were to write an AnagramQuery, you would first have to add queryparser support anyway to it. But, if you want anagrams you could just write an anagram tokenfilter that sorts the characters in the termbuffer: then you wouldn't need to write a custom query, nor custom queryparser integration, and it would be fast. Determine if prefix, wildcard, fuzzy queries should be lowercased - Key: SOLR-219 URL: https://issues.apache.org/jira/browse/SOLR-219 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Minor Fix For: 3.3 Attachments: lowercase_prefix.patch, wildcardlowercase.patch Solr should be able to do the right thing when doing prefix/wildcard/fuzzy queries on fields with respect to lowercasing or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-3.x - Build # 413 - Still Failing
Build: https://builds.apache.org/job/Lucene-3.x/413/ 1 tests failed. FAILED: org.apache.lucene.util.fst.TestFSTs.testBigSet Error Message: Java heap space Stack Trace: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.util.IntsRef.copy(IntsRef.java:111) at org.apache.lucene.util.IntsRef.init(IntsRef.java:44) at org.apache.lucene.util.fst.TestFSTs$FSTTester.verifyPruned(TestFSTs.java:791) at org.apache.lucene.util.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:499) at org.apache.lucene.util.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:363) at org.apache.lucene.util.fst.TestFSTs.doTest(TestFSTs.java:211) at org.apache.lucene.util.fst.TestFSTs.testRandomWords(TestFSTs.java:944) at org.apache.lucene.util.fst.TestFSTs.testBigSet(TestFSTs.java:964) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1272) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1190) Build Log (for compile errors): [...truncated 12498 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2609) Coordinate range queries do not work with Spatial Solr
Coordinate range queries do not work with Spatial Solr -- Key: SOLR-2609 URL: https://issues.apache.org/jira/browse/SOLR-2609 Project: Solr Issue Type: Bug Components: SearchComponents - other Affects Versions: 3.1 Reporter: Zac Smith The Spatial Search documentation states that you can create your own bounding box using a range query: Since the LatLonType field also supports field queries and range queries, one can manually create their own bounding box rather than using bbox: ...q=*:*fq=store:[45,-94 TO 46,-93] This works unless your range covers an area where longitude goes from 180 to -180. For instance I want all items in the longitude range of 178 to -177 which of course gives no results (it is not a valid numeric range). It's not really surprising that this doesn't work as it is just a standard range query with no spatial filters being applied. I am wondering if this is just an issue with the documentation and there is another way that this should be done? Please advise if more details are needed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3215) SloppyPhraseScorer sometimes computes Infinite freq
SloppyPhraseScorer sometimes computes Infinite freq --- Key: LUCENE-3215 URL: https://issues.apache.org/jira/browse/LUCENE-3215 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-3215_test.patch reported on user list: http://www.lucidimagination.com/search/document/400cbc528ed63db9/score_of_infinity_on_dismax_query -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3215) SloppyPhraseScorer sometimes computes Infinite freq
[ https://issues.apache.org/jira/browse/LUCENE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3215: Attachment: LUCENE-3215_test.patch test case SloppyPhraseScorer sometimes computes Infinite freq --- Key: LUCENE-3215 URL: https://issues.apache.org/jira/browse/LUCENE-3215 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-3215_test.patch reported on user list: http://www.lucidimagination.com/search/document/400cbc528ed63db9/score_of_infinity_on_dismax_query -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3215) SloppyPhraseScorer sometimes computes Infinite freq
[
https://issues.apache.org/jira/browse/LUCENE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051786#comment-13051786
]
Robert Muir commented on LUCENE-3215:
-
the problem in this case, is it computes a 'matchLength' of -1.
then the default impl of sloppyFreq divides by zero, because its defined as:
{noformat}
return 1.0f / (distance + 1);
{noformat}
SloppyPhraseScorer sometimes computes Infinite freq
---
Key: LUCENE-3215
URL: https://issues.apache.org/jira/browse/LUCENE-3215
Project: Lucene - Java
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-3215_test.patch
reported on user list:
http://www.lucidimagination.com/search/document/400cbc528ed63db9/score_of_infinity_on_dismax_query
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-219) Determine if prefix, wildcard, fuzzy queries should be lowercased
[ https://issues.apache.org/jira/browse/SOLR-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051789#comment-13051789 ] Mike Sokolov commented on SOLR-219: --- Yes, I've implemented anagram querying as you indicated, by sorting the letters, but the query I have in mind would allow some wildcards as well. An example comes up in scrabble with the blanks, and we've been asked to implement this for some dictionary sites. I was wondering if that could be implemented in Lucene as an FST: I suspect it could, but my brain went numb trying to come up with a regex as a way to get there, and then I ended up building using a direct hand-coded term scanning approach. Re: the question of mapping queries, I may very well be missing something here. Maybe I've misunderstood your plan: isn't it that Phrase-type queries go through the phrase-analyzer, TermQuery goes through the regular (query) analyzer, and MultiTermQueries go through the wildcard-analyzer? It just seemed to me that there might be new Queries written in the future that might not easily be categorized into one of those classes, or that it might not be obvious how to indicate which class is thr right one, and it could be handy to have a way to associate them with an analysis chain in the way you've described. Although it seems that my one example probably falls into the MTQ category and I guess (?) would just pick up the wildcard analysis chain, which is probably the right thing. Determine if prefix, wildcard, fuzzy queries should be lowercased - Key: SOLR-219 URL: https://issues.apache.org/jira/browse/SOLR-219 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Minor Fix For: 3.3 Attachments: lowercase_prefix.patch, wildcardlowercase.patch Solr should be able to do the right thing when doing prefix/wildcard/fuzzy queries on fields with respect to lowercasing or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3215) SloppyPhraseScorer sometimes computes Infinite freq
[ https://issues.apache.org/jira/browse/LUCENE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3215: Attachment: LUCENE-3215_test.patch those lyrics are entertaining, but here is a more concise test. SloppyPhraseScorer sometimes computes Infinite freq --- Key: LUCENE-3215 URL: https://issues.apache.org/jira/browse/LUCENE-3215 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-3215_test.patch, LUCENE-3215_test.patch reported on user list: http://www.lucidimagination.com/search/document/400cbc528ed63db9/score_of_infinity_on_dismax_query -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-219) Determine if prefix, wildcard, fuzzy queries should be lowercased
[
https://issues.apache.org/jira/browse/SOLR-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051801#comment-13051801
]
Robert Muir commented on SOLR-219:
--
{quote}
It just seemed to me that there might be new Queries written in the future that
might not easily be categorized into one of those classes
{quote}
I'm not worried about this to be honest... an inverted index has terms and
positions so there are really only so many possibilities.
I think its enough to say, here is the analysis chain for terms, for positions,
and for multitermqueries that rewrite to these.
Even if there were 200,000 new queries about to be added, it doesn't make sense
to worry about that here, because first they would need queryparser support.
Determine if prefix, wildcard, fuzzy queries should be lowercased
-
Key: SOLR-219
URL: https://issues.apache.org/jira/browse/SOLR-219
Project: Solr
Issue Type: Improvement
Reporter: Yonik Seeley
Priority: Minor
Fix For: 3.3
Attachments: lowercase_prefix.patch, wildcardlowercase.patch
Solr should be able to do the right thing when doing prefix/wildcard/fuzzy
queries on fields with respect to lowercasing or not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
