Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build [mkdir] Created dir: /tmp/apache-solr-nightly/build/web compile-solrj: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj [javac] Compiling 88 source files to /tmp/apache-solr-nightly/build/solrj [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solr [javac] Compiling 434 source files to /tmp/apache-solr-nightly/build/solr [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 210 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. dist-contrib: init: [mkdir] Created dir: /tmp/apache-solr-nightly/contrib/clustering/build/classes [mkdir] Created dir: /tmp/apache-solr-nightly/contrib/clustering/lib/downloads [mkdir] Created dir: /tmp/apache-solr-nightly/build/docs/api init-forrest-entities: compile-solrj: compile: [javac] Compiling 1 source file to /tmp/apache-solr-nightly/build/solr [javac] Note: /tmp/apache-solr-nightly/src/java/org/apache/solr/search/DocSetHitCollector.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. make-manifest: [mkdir] Created dir: /tmp/apache-solr-nightly/build/META-INF proxy.setup: check-files: get-colt: [get] Getting: http://repo1.maven.org/maven2/colt/colt/1.2.0/colt-1.2.0.jar [get] To: /tmp/apache-solr-nightly/contrib/clustering/lib/downloads/colt-1.2.0.jar get-pcj: [get] Getting: http://repo1.maven.org/maven2/pcj/pcj/1.2/pcj-1.2.jar [get] To: /tmp/apache-solr-nightly/contrib/clustering/lib/downloads/pcj-1.2.jar get-nni: [get] Getting: http://download.carrot2.org/maven2/org/carrot2/nni/1.0.0/nni-1.0.0.jar [get] To: /tmp/apache-solr-nightly/contrib/clustering/lib/downloads/nni-1.0.0.jar get-simple-xml: [get] Getting: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/simpleframework/simple-xml/1.7.3/simple-xml-1.7.3.jar [get] To: /tmp/apache-solr-nightly/contrib/clustering/lib/downloads/simple-xml-1.7.3.jar get-libraries: compile: [javac] Compiling 7 source files to /tmp/apache-solr-nightly/contrib/clustering/build/classes [javac] Note: /tmp/apache-solr-nightly/contrib/clustering/src/main/java/org/apache/solr/handler/clustering/carrot2/CarrotClusteringEngine.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. build: [jar] Building jar: /tmp/apache-solr-nightly/contrib/clustering/build/apache-solr-clustering-1.5-dev.jar dist: [copy] Copying 1 file to /tmp/apache-solr-nightly/dist init: [mkdir] Created dir: /tmp/apache-solr-nightly/contrib/dataimporthandler/target/classes init-forrest-entities: compile-solrj: compile: [javac] Compiling 1 source file to /tmp/apache-solr-nightly/build/solr [javac] Note: /tmp/apache-solr-nightly/src/java/org/apache/solr/search/DocSetHitCollector.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. make-manifest: compile: [javac] Compiling 49 source files to /tmp/apache-solr-nightly/contrib/dataimporthandler/target/classes [javac] Note: /tmp/apache-solr-nightly/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DocBuilder.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compileExtras: [mkdir] Created dir: /tmp/apache-solr-nightly/contrib/dataimporthandler/target/extras/classes [javac] Compiling 2 source files to /tmp/apache-solr-nightly/contrib/dataimporthandler/target/extras/classes [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. build: [jar] Building jar: /tmp/apache-solr-nightly/contrib/dataimporthandler/target/apache-solr-dataimporthandler-1.5-dev.jar [jar] Building jar:
Build failed in Hudson: Solr-trunk #1077
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/1077/changes Changes: [markrmiller] SOLR-1722: small bug - defaultCoreName is looked for at /solr, but should be /solr/cores - also, defaultCoreName should really not default to DEFAULT_DEFAULT_CORENAME -- [...truncated 2369 lines...] [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.952 sec [junit] Running org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.333 sec [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.407 sec [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.008 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 20.627 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleJettyTest [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 27.114 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 24.812 sec [junit] Running org.apache.solr.client.solrj.embedded.TestSolrProperties [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.005 sec [junit] Running org.apache.solr.client.solrj.request.TestUpdateRequestCodec [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.413 sec [junit] Running org.apache.solr.client.solrj.response.AnlysisResponseBaseTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.501 sec [junit] Running org.apache.solr.client.solrj.response.DocumentAnalysisResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.415 sec [junit] Running org.apache.solr.client.solrj.response.FieldAnalysisResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.414 sec [junit] Running org.apache.solr.client.solrj.response.QueryResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.56 sec [junit] Running org.apache.solr.client.solrj.response.TermsResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.213 sec [junit] Running org.apache.solr.client.solrj.response.TestSpellCheckResponse [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 7.379 sec [junit] Running org.apache.solr.client.solrj.util.ClientUtilsTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.409 sec [junit] Running org.apache.solr.common.SolrDocumentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.443 sec [junit] Running org.apache.solr.common.params.ModifiableSolrParamsTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.414 sec [junit] Running org.apache.solr.common.params.SolrParamTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.541 sec [junit] Running org.apache.solr.common.util.ContentStreamTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.443 sec [junit] Running org.apache.solr.common.util.DOMUtilTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.537 sec [junit] Running org.apache.solr.common.util.FileUtilsTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.417 sec [junit] Running org.apache.solr.common.util.IteratorChainTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.438 sec [junit] Running org.apache.solr.common.util.NamedListTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.395 sec [junit] Running org.apache.solr.common.util.TestFastInputStream [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.923 sec [junit] Running org.apache.solr.common.util.TestHash [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.526 sec [junit] Running org.apache.solr.common.util.TestNamedListCodec [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.692 sec [junit] Running org.apache.solr.common.util.TestXMLEscaping [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.41 sec [junit] Running org.apache.solr.core.AlternateDirectoryTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.456 sec [junit] Running org.apache.solr.core.AlternateIndexReaderTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.327 sec [junit] Running org.apache.solr.core.IndexReaderFactoryTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.196 sec [junit] Running org.apache.solr.core.RequestHandlersTest [junit] Tests run: 2, Failures: 0, Errors: 0,
[jira] Commented: (SOLR-1809) Carrot2 clustering time logging
[ https://issues.apache.org/jira/browse/SOLR-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842249#action_12842249 ] Erik Hatcher commented on SOLR-1809: Stanislaw - how does this differ from the output debugQuery=true provides on the component timings? Isn't that sufficient? Carrot2 clustering time logging --- Key: SOLR-1809 URL: https://issues.apache.org/jira/browse/SOLR-1809 Project: Solr Issue Type: Improvement Components: contrib - Clustering Reporter: Stanislaw Osinski Fix For: 1.5 Attachments: SOLR-1809.patch It may be useful to log the amount of time Carrot2 spent on clustering. This should be helpful when debugging performance issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
A bit off topic, but...
Sorry to put this on the dev list, but the folks who read this are also some of the heavy hitters on the user list I'm seeing questions on the users list of the form help, it doesn't work, which then requires people to guess, ask for clarification, etc. I often try to grab them long enough to ask for more information and take some of the load off the folks who really know things, but I'm starting to get frustrated with the number of really vague posts that require three back-and-forths before anything useful comes of it. In, I admit, 2 minutes of looking I couldn't find anything on the SOLR site about how to use the user's list. Would it be useful If I created a much gentler (and shorter) version of http://catb.org/~esr/faqs/smart-questions.html? If it'd be useful, is it worth putting on the SOLR website? Or maybe Chris would be willing to put it on his apache page so we could link to it easily. My goal here would be to have something welcoming (the above is pretty darn off-putting, even if it accurately reflects my reactions sometime), but at the same time conveying that there are things the poster can do to 1 get answers much more quickly and 2 stop wasting everyone's time (OK, a little frustration there). I know my first questions on the Lucene list sure could have used a bit of etiquette guidance, but I'm not sure I'd have appreciated something in the tone of the link above. That said, I'm tired of typing the same request for more information over and over and over... Or, someone could say Do you mean this page url here and I'll just blush in the privacy of my study Whaddya think? Erick
Re: A bit off topic, but...
I think something would definitely be useful. Something *short* that people will read and can actually follow. Something that tells them what we will ask first in trying to diagnose a problem. Something/somewhere that they will be likely to run across before posting a question. Maybe right near the top of the solr faq or something? Along the lines of If you're having a problem with X, ... post to solr-user with A B, C We should keep the list small, or give different lists depending on the problem. We don't want people to have to fill out a 10 page form to ask for help :-) -Yonik http://www.lucidimagination.com On Sat, Mar 6, 2010 at 9:58 AM, Erick Erickson erickerick...@gmail.com wrote: Sorry to put this on the dev list, but the folks who read this are also some of the heavy hitters on the user list I'm seeing questions on the users list of the form help, it doesn't work, which then requires people to guess, ask for clarification, etc. I often try to grab them long enough to ask for more information and take some of the load off the folks who really know things, but I'm starting to get frustrated with the number of really vague posts that require three back-and-forths before anything useful comes of it. In, I admit, 2 minutes of looking I couldn't find anything on the SOLR site about how to use the user's list. Would it be useful If I created a much gentler (and shorter) version of http://catb.org/~esr/faqs/smart-questions.html? If it'd be useful, is it worth putting on the SOLR website? Or maybe Chris would be willing to put it on his apache page so we could link to it easily. My goal here would be to have something welcoming (the above is pretty darn off-putting, even if it accurately reflects my reactions sometime), but at the same time conveying that there are things the poster can do to 1 get answers much more quickly and 2 stop wasting everyone's time (OK, a little frustration there). I know my first questions on the Lucene list sure could have used a bit of etiquette guidance, but I'm not sure I'd have appreciated something in the tone of the link above. That said, I'm tired of typing the same request for more information over and over and over... Or, someone could say Do you mean this page url here and I'll just blush in the privacy of my study Whaddya think? Erick
[jira] Assigned: (SOLR-1798) Memory leak in FastLRUCache
[
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley reassigned SOLR-1798:
--
Assignee: Yonik Seeley
Memory leak in FastLRUCache
---
Key: SOLR-1798
URL: https://issues.apache.org/jira/browse/SOLR-1798
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4, 1.5
Reporter: Laxman
Assignee: Yonik Seeley
Fix For: 1.5
Every time a commit happens two Stats instances
[org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative
cache statistics causing this Stats object leak.
{noformat}
cumulativeStats = (ListConcurrentLRUCache.Stats) persistence;
cumulativeStats.add(cache.getStats());
{noformat}
Everytime a *commit* happens a new cache object is getting created and its
stats is added to the list which is not released at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1798) Memory leak in FastLRUCache
[
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-1798:
---
Attachment: SOLR-1798.patch
I think the fix is as simple as this patch.
Verifying that it fixes it is slightly harder - I'll try breaking out the
profiler.
Memory leak in FastLRUCache
---
Key: SOLR-1798
URL: https://issues.apache.org/jira/browse/SOLR-1798
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4, 1.5
Reporter: Laxman
Assignee: Yonik Seeley
Fix For: 1.5
Attachments: SOLR-1798.patch
Every time a commit happens two Stats instances
[org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative
cache statistics causing this Stats object leak.
{noformat}
cumulativeStats = (ListConcurrentLRUCache.Stats) persistence;
cumulativeStats.add(cache.getStats());
{noformat}
Everytime a *commit* happens a new cache object is getting created and its
stats is added to the list which is not released at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1798) Memory leak in FastLRUCache
[
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842319#action_12842319
]
Yonik Seeley commented on SOLR-1798:
Hmmm, right - fixes the memory leak, but breaks cumulative stats.
Memory leak in FastLRUCache
---
Key: SOLR-1798
URL: https://issues.apache.org/jira/browse/SOLR-1798
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4, 1.5
Reporter: Laxman
Assignee: Yonik Seeley
Fix For: 1.5
Attachments: SOLR-1798.patch
Every time a commit happens two Stats instances
[org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative
cache statistics causing this Stats object leak.
{noformat}
cumulativeStats = (ListConcurrentLRUCache.Stats) persistence;
cumulativeStats.add(cache.getStats());
{noformat}
Everytime a *commit* happens a new cache object is getting created and its
stats is added to the list which is not released at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1798) Memory leak in FastLRUCache
[
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-1798:
---
Attachment: SOLR-1798.patch
New patch that fixes the cumulative stats by adding in an entry in the list for
cumulative stats and incrementing them for every cache that is closed.
Longer term, we might want a hash set or something (if we start having
per-segment caches) but more changes will be necessary then anyway.
Memory leak in FastLRUCache
---
Key: SOLR-1798
URL: https://issues.apache.org/jira/browse/SOLR-1798
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4, 1.5
Reporter: Laxman
Assignee: Yonik Seeley
Fix For: 1.5
Attachments: SOLR-1798.patch, SOLR-1798.patch
Every time a commit happens two Stats instances
[org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative
cache statistics causing this Stats object leak.
{noformat}
cumulativeStats = (ListConcurrentLRUCache.Stats) persistence;
cumulativeStats.add(cache.getStats());
{noformat}
Everytime a *commit* happens a new cache object is getting created and its
stats is added to the list which is not released at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1798) Memory leak in FastLRUCache
[
https://issues.apache.org/jira/browse/SOLR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-1798.
Resolution: Fixed
committed.
Memory leak in FastLRUCache
---
Key: SOLR-1798
URL: https://issues.apache.org/jira/browse/SOLR-1798
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4, 1.5
Reporter: Laxman
Assignee: Yonik Seeley
Fix For: 1.5
Attachments: SOLR-1798.patch, SOLR-1798.patch
Every time a commit happens two Stats instances
[org.apache.solr.common.util.ConcurrentLRUCache.Stats] are leaking.
Following code [org.apache.solr.search.FastLRUCache] to maintain cumulative
cache statistics causing this Stats object leak.
{noformat}
cumulativeStats = (ListConcurrentLRUCache.Stats) persistence;
cumulativeStats.add(cache.getStats());
{noformat}
Everytime a *commit* happens a new cache object is getting created and its
stats is added to the list which is not released at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: A bit off topic, but...
OK, there's a first cut at this page up on the Wiki, see: http://wiki.apache.org/solr/UsingMailingLists.html I linked to it off the FAQ, I just added a link from the Are there mailing lists for SOLR section at: http://wiki.apache.org/solr/FAQ#Are_there_Mailing_lists_for_Solr.3F I *think* I got the links right, although it took a few tries. Some of which I forgot to comment on, sorry 'bout that. I'm not sure whether it's too long or not. My intention here is to have a page we can direct people to with some admonition like please read this and repost your question. I don't think it should turn into a list of specific problem solutions. But I can see expanding it with other categories like: memory issues search performance multiple cores fill in your favorite topic here With the caveat that for each, all the page should do is identify the information the poster should include when asking for help rather than solutions. If we bury the how to ask in a thousand lines of possible solutions, eyes will glaze over Best Erick On Sat, Mar 6, 2010 at 10:15 AM, Yonik Seeley yo...@lucidimagination.comwrote: I think something would definitely be useful. Something *short* that people will read and can actually follow. Something that tells them what we will ask first in trying to diagnose a problem. Something/somewhere that they will be likely to run across before posting a question. Maybe right near the top of the solr faq or something? Along the lines of If you're having a problem with X, ... post to solr-user with A B, C We should keep the list small, or give different lists depending on the problem. We don't want people to have to fill out a 10 page form to ask for help :-) -Yonik http://www.lucidimagination.com On Sat, Mar 6, 2010 at 9:58 AM, Erick Erickson erickerick...@gmail.com wrote: Sorry to put this on the dev list, but the folks who read this are also some of the heavy hitters on the user list I'm seeing questions on the users list of the form help, it doesn't work, which then requires people to guess, ask for clarification, etc. I often try to grab them long enough to ask for more information and take some of the load off the folks who really know things, but I'm starting to get frustrated with the number of really vague posts that require three back-and-forths before anything useful comes of it. In, I admit, 2 minutes of looking I couldn't find anything on the SOLR site about how to use the user's list. Would it be useful If I created a much gentler (and shorter) version of http://catb.org/~esr/faqs/smart-questions.htmlhttp://catb.org/%7Eesr/faqs/smart-questions.html? If it'd be useful, is it worth putting on the SOLR website? Or maybe Chris would be willing to put it on his apache page so we could link to it easily. My goal here would be to have something welcoming (the above is pretty darn off-putting, even if it accurately reflects my reactions sometime), but at the same time conveying that there are things the poster can do to 1 get answers much more quickly and 2 stop wasting everyone's time (OK, a little frustration there). I know my first questions on the Lucene list sure could have used a bit of etiquette guidance, but I'm not sure I'd have appreciated something in the tone of the link above. That said, I'm tired of typing the same request for more information over and over and over... Or, someone could say Do you mean this page url here and I'll just blush in the privacy of my study Whaddya think? Erick
[jira] Commented: (SOLR-1807) UpdateHandler plugin is not fully supported
[
https://issues.apache.org/jira/browse/SOLR-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842369#action_12842369
]
Shalin Shekhar Mangar commented on SOLR-1807:
-
UpdateHandler is an interface so instead of adding a method to it and breaking
compatibility, we added it to the DirectUpdateHandler2 class. I guess the only
way is to change the UpdateHandler interface.
UpdateHandler plugin is not fully supported
---
Key: SOLR-1807
URL: https://issues.apache.org/jira/browse/SOLR-1807
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 1.4
Reporter: John Wang
UpdateHandler is published as a supported Plugin, but code such as the
following:
if (core.getUpdateHandler() instanceof DirectUpdateHandler2) {
((DirectUpdateHandler2)
core.getUpdateHandler()).forceOpenWriter();
} else {
LOG.warn(The update handler being used is not an instance or
sub-class of DirectUpdateHandler2. +
Replicate on Startup cannot work.);
}
suggest that it is really not fully supported.
Must all implementations of UpdateHandler be subclasses of
DirectUpdateHandler2 for it to work with replication?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
