[jira] [Assigned] (SOLR-2124) SEVERE exceptions are being logged for expected PingRequestHandler SERVICE_UNAVAILABLE exceptions
[
https://issues.apache.org/jira/browse/SOLR-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer reassigned SOLR-2124:
Assignee: James Dyer
SEVERE exceptions are being logged for expected PingRequestHandler
SERVICE_UNAVAILABLE exceptions
-
Key: SOLR-2124
URL: https://issues.apache.org/jira/browse/SOLR-2124
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: James Dyer
Fix For: 3.6, 4.0
Attachments: SOLR-2124.patch
As reported by a user, if you use the PingRequestHandler, and the
corrisponding helthcheck file doesn't exist (and expected situation when a
server is out of rotation) Solr is logging a SEVERE error...
{noformat}
SEVERE: org.apache.solr.common.SolrException: Service disabled
at
org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:48)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1324)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{noformat}
This is in spite of hte fact that PingRequestHandler explicitly sets the
alreadyLogged boolean to true in the SolrException constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-2933) DIHCacheSupport ignores left side of where=xid=x.id attribute
[ https://issues.apache.org/jira/browse/SOLR-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer reassigned SOLR-2933: Assignee: James Dyer DIHCacheSupport ignores left side of where=xid=x.id attribute --- Key: SOLR-2933 URL: https://issues.apache.org/jira/browse/SOLR-2933 Project: Solr Issue Type: Sub-task Components: contrib - DataImportHandler Affects Versions: 4.0 Reporter: Mikhail Khludnev Assignee: James Dyer Priority: Minor Labels: noob, random Attachments: AbstractDataImportHandlerTestCase.java-choose-map-randomly.patch, SOLR-2933.patch Original Estimate: 1h Remaining Estimate: 1h DIHCacheSupport introduced at SOLR-2382 uses new config attributes cachePk and cacheLookup. But support old one where=xid=x.id is broken by [DIHCacheSupport.init|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DIHCacheSupport.java?view=markup] - it never put where= sides into the context, but it revealed by [SortedMapBackedCache.init|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/SortedMapBackedCache.java?view=markup], which takes just first column as a primary key. That's why all tests are green. To reproduce the issue I need just reorder entry at [line 219|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestCachedSqlEntityProcessor.java?revision=1201659view=markup] and make desc first and picked up as a primary key. To do that I propose to chose concrete map class randomly for all DIH test cases at [createMap()|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/AbstractDataImportHandlerTestCase.java?revision=1149600view=markup]. I'm attaching test breaking patch and seed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3033) numberToKeep on replication handler does not work with backupAfter
[ https://issues.apache.org/jira/browse/SOLR-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer reassigned SOLR-3033: Assignee: James Dyer numberToKeep on replication handler does not work with backupAfter -- Key: SOLR-3033 URL: https://issues.apache.org/jira/browse/SOLR-3033 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 3.5 Environment: openjdk 1.6, linux 3.x Reporter: Torsten Krah Assignee: James Dyer Attachments: SOLR-3033.patch Configured my replication handler like this: requestHandler name=/replication class=solr.ReplicationHandler lst name=master str name=replicateAfterstartup/str str name=replicateAftercommit/str str name=replicateAfteroptimize/str str name=confFileselevate.xml,schema.xml,spellings.txt,stopwords.txt,stopwords_de.txt,stopwords_en.txt,synonyms_de.txt,synonyms.txt/str str name=backupAfteroptimize/str str name=numberToKeep1/str /lst /requestHandler So after optimize a snapshot should be taken, this works. But numberToKeep is ignored, snapshots are increasing with each call to optimize and are kept forever. Seems this settings have no effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-2947) DIH caching bug - EntityRunner destroys child entity processor
[ https://issues.apache.org/jira/browse/SOLR-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer reassigned SOLR-2947: Assignee: James Dyer DIH caching bug - EntityRunner destroys child entity processor -- Key: SOLR-2947 URL: https://issues.apache.org/jira/browse/SOLR-2947 Project: Solr Issue Type: Sub-task Components: contrib - DataImportHandler Affects Versions: 4.0 Reporter: Mikhail Khludnev Assignee: James Dyer Labels: noob Fix For: 4.0 Attachments: SOLR-2947.patch, SOLR-2947.patch, SOLR-2947.patch, SOLR-2947.patch, SOLR-2947.patch, dih-cache-destroy-on-threads-fix.patch, dih-cache-threads-enabling-bug.patch My intention is fix multithread import with SQL cache. Here is the 2nd stage. If I enable DocBuilder.EntityRunner flow even for single thread, it breaks the pretty basic functionality: parent-child join. the reason is [line 473 entityProcessor.destroy();|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DocBuilder.java?revision=1201659view=markup] breaks children entityProcessor. see attachement comments for more details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-2847) fix test bug in DistributedSpellCheckComponentTest
[ https://issues.apache.org/jira/browse/SOLR-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer reassigned SOLR-2847: Assignee: James Dyer fix test bug in DistributedSpellCheckComponentTest -- Key: SOLR-2847 URL: https://issues.apache.org/jira/browse/SOLR-2847 Project: Solr Issue Type: Bug Components: multicore, spellchecker Affects Versions: 4.0 Reporter: James Dyer Assignee: James Dyer Priority: Trivial Fix For: 4.0 Attachments: SOLR-2847.patch In Trunk, the IndexBasedSpellChecker dictionary is not being built both for the control and shard indexes. The test then compares nothing to nothing and passes, because both the shard-index response and the control-index responses are the same. This issue fixes the problem with the dictionaries not being built and also adds an additional check for data in the control-index responses so that this sort of regression may be detected in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
