[
https://issues.apache.org/jira/browse/SOLR-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900161#comment-17900161
]
Chris M. Hostetter commented on SOLR-6934:
------------------------------------------
I think given the existence of {{./bin/solr assert}} this ticket is definitely
still something that has space for easy wins.
I would suggest that all the {{lsof}} and {{ps}} shell script specific logic
and an around here...
{noformat}
echo -n "Waiting up to $SOLR_START_WAIT seconds to see Solr running on
port $SOLR_PORT"
# Launch in a subshell to show the spinner
(loops=0
while true
do
running=$(lsof -t -PniTCP:$SOLR_PORT -sTCP:LISTEN || :)
if [ -z "${running:-}" ]; then
slept=$((loops * 2))
if [ $slept -lt $SOLR_START_WAIT ]; then
sleep 2
loops=$((loops+1))
else
echo -e "Still not seeing Solr listening on $SOLR_PORT after
$SOLR_START_WAIT seconds!"
tail -30 "$SOLR_LOGS_DIR/solr.log"
exit # subshell!
fi
else
SOLR_PID=$(ps auxww | grep start\.jar | awk
"/\-Djetty\.port=$SOLR_PORT/"' {print $2}' | sort -r)
echo -e "\nStarted Solr server on port $SOLR_PORT (pid=$SOLR_PID).
Happy searching!\n"
exit # subshell!
fi
done) &
{noformat}
...should probably be ripped out and replaced with one or more calls to
{{./bin/solr assert ...}}
(Both to simplify the shell code & eliminate the {{lsof}} dependency -- but
also, IIUC – give a useful error if *something* is listening to {{$SOLR_PORT}}
that isn't Solr)
> bin/solr -e cloud has poor failure behavior when solr has (certain types of)
> startup errors
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-6934
> URL: https://issues.apache.org/jira/browse/SOLR-6934
> Project: Solr
> Issue Type: Bug
> Reporter: Chris M. Hostetter
> Priority: Major
>
> Earlier today, sarowe backported a jetty config change that broke 5x because
> it refered to a jetty feature that only existed in jetty9 (5x still using
> jetty8).
> Ass a result, jetty started up and was listenting on the specified port - but
> the solr webapp code never loaded.
> this caused an interesting failure behavior in bin/solr...
> {noformat}
> hossman@frisbee:~/lucene/5x_dev/solr$ bin/solr -e cloud -noprompt
> Welcome to the SolrCloud example!
> Starting up 2 Solr nodes for your example SolrCloud cluster.
> Creating Solr home directory
> /home/hossman/lucene/5x_dev/solr/example/cloud/node1/solr
> Cloning Solr home directory
> /home/hossman/lucene/5x_dev/solr/example/cloud/node1 into
> /home/hossman/lucene/5x_dev/solr/example/cloud/node2
> Starting up SolrCloud node1 on port 8983 using command:
> solr start -cloud -s
> /home/hossman/lucene/5x_dev/solr/example/cloud/node1/solr -p 8983
> Waiting to see Solr listening on port 8983 [/]
> Started Solr server on port 8983 (pid=29954). Happy searching!
>
> Starting node2 on port 7574 using command:
> solr start -cloud -s
> /home/hossman/lucene/5x_dev/solr/example/cloud/node2/solr -p 7574 -z
> localhost:9983
> Waiting to see Solr listening on port 7574 [/]
> Started Solr server on port 7574 (pid=30099). Happy searching!
> Exception in thread "main" org.noggit.JSONParser$ParseException: JSON Parse
> Error: char=<,position=0 BEFORE='<' AFTER='html> <head> <meta
> http-equiv="Content-'
> at org.noggit.JSONParser.err(JSONParser.java:356)
> at org.noggit.JSONParser.handleNonDoubleQuoteString(JSONParser.java:712)
> at org.noggit.JSONParser.next(JSONParser.java:886)
> at org.noggit.JSONParser.nextEvent(JSONParser.java:930)
> at org.noggit.ObjectBuilder.<init>(ObjectBuilder.java:44)
> at org.noggit.ObjectBuilder.getVal(ObjectBuilder.java:37)
> at
> org.apache.solr.util.SolrCLI$SolrResponseHandler.handleResponse(SolrCLI.java:447)
> at
> org.apache.solr.util.SolrCLI$SolrResponseHandler.handleResponse(SolrCLI.java:443)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:218)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:160)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:136)
> at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:469)
> at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:422)
> at
> org.apache.solr.util.SolrCLI$CreateCollectionTool.runTool(SolrCLI.java:1081)
> at org.apache.solr.util.SolrCLI.main(SolrCLI.java:195)
> SolrCloud example running, please visit http://localhost:8983/solr
> {noformat}
> we should make bin/solr a little smarter in failure cases like this --
> perhaps the "Waiting to see Solr listening on port 7574" check should be more
> aggressive, and actually verify that something like /admin/cores returns 200
> and a parsable JSON response?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
