[
https://issues.apache.org/jira/browse/SOLR-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557537#comment-14557537
]
Timothy Potter commented on SOLR-7587:
--------------------------------------
Hmmm ... I'm not seeing the other thread that the one Hoss pasted in above is
blocked on in the thread dumps?
Anyway, this looks to be related to how EmbeddedSolrServer initializes the
SolrCore as the currSearcher should not be null at this point in the test (a
commit after a deleteByQuery) ... I would have thought the firstSearcher event
(which is what the VersionBucket code hangs off of) would have fired already
during core initialization and not at the time of commit.
Need to step away for today, but will work on it more tomorrow (Sunday) ...
seems solvable but I don't want to just hack something in right now. My first
thought is to move the call to {{UpdateLog.onFirstSearcher}} into the Callable
executed by the searcherExecutor, i.e.
{code}
Index: src/java/org/apache/solr/core/SolrCore.java
===================================================================
--- src/java/org/apache/solr/core/SolrCore.java (revision 1681226)
+++ src/java/org/apache/solr/core/SolrCore.java (working copy)
@@ -1806,14 +1806,15 @@
}
if (currSearcher == null) {
- if (updateHandler != null && updateHandler.getUpdateLog() != null) {
- updateHandler.getUpdateLog().onFirstSearcher(newSearcher);
- }
-
future = searcherExecutor.submit(new Callable() {
@Override
public Object call() throws Exception {
try {
+
+ if (updateHandler != null && updateHandler.getUpdateLog() !=
null) {
+ updateHandler.getUpdateLog().onFirstSearcher(newSearcher);
+ }
+
for (SolrEventListener listener : firstSearcherListeners) {
listener.newSearcher(newSearcher, null);
}
{code}
that would likely address this issue, but when I originally did that, I started
seeing a bunch of warnings about multiple on-deck searchers (probably because
doing the version bucket lookup takes some time?)
> TestSpellCheckResponse stalled and never timed out -- possible VersionBucket
> bug? (5.2 branch)
> ----------------------------------------------------------------------------------------------
>
> Key: SOLR-7587
> URL: https://issues.apache.org/jira/browse/SOLR-7587
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Timothy Potter
> Priority: Blocker
> Fix For: 5.2
>
> Attachments: jstack.1.txt, jstack.2.txt,
> junit4-J0-20150522_181244_599.events, junit4-J0-20150522_181244_599.spill,
> junit4-J0-20150522_181244_599.suites
>
>
> On the 5.2 branch (r1681250), I encountered a solrj test stalled for over 110
> minutes before i finally killed it...
> {noformat}
> [junit4] Suite: org.apache.solr.common.util.TestRetryUtil
> [junit4] Completed [55/60] on J1 in 1.04s, 1 test
> [junit4]
> [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T18:14:56, stalled for
> 121s at: TestSpellCheckResponse.testSpellCheckResponse
> [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T18:15:56, stalled for
> 181s at: TestSpellCheckResponse.testSpellCheckResponse
> ...
> [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T20:00:56, stalled for
> 6481s at: TestSpellCheckResponse.testSpellCheckResponse
> [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T20:01:56, stalled for
> 6541s at: TestSpellCheckResponse.testSpellCheckResponse
> [junit4] HEARTBEAT J0 PID(12147@tray): 2015-05-22T20:02:56, stalled for
> 6601s at: TestSpellCheckResponse.testSpellCheckResponse
> {noformat}
> I'll attach some jstack output as well as all the temp files from the J0
> runner.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
