[
https://issues.apache.org/jira/browse/SOLR-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926853#comment-16926853
]
Robert Bunch edited comment on SOLR-11492 at 9/11/19 12:41 AM:
---
script works on Mac OS (Mojave) and CentOS 6.
however, on Mac OS, w/ master branch build of Solr – using "-c" option to
harvest the collections results in repeatably *{color:#ff}rebooting{color}*
the Mac! (not running it as root...)
on CentOS 6, after the Solr JVMs have been restarted (and verified w/
CLUSTERSTATUS, LIST) – eventually OS threads are exhausted:
{code:java}
[bunchr@localhost lab]$ ls
bash: fork: retry: Resource temporarily unavailable
bash: fork: retry: Resource temporarily unavailable
bash: fork: retry: Resource temporarily unavailable
bash: fork: retry: Resource temporarily unavailable
:
:
:{code}
...and pretty much have to reboot (further investigations at the *nix level are
warranted) or nuke the JVMs to get the box back under control.
Workaround is to stop solr via script (or kill -9 `pgrep -f start.jar`), and do
a deleteall /solr.../collections/... (whatever needs to be cleaned up). inside
start() after SAFE_DEST is defined:
{code:java}
275 # RTB 2019-09-10
276 echo COLLECTIONS FOUND IN ZK | egrep --color=always '.*'
277 COLLECTIONS_TO_CLEAN=`${SOLR}/bin/solr zk ls
/solr_${SAFE_DEST}/collections -z localhost:2181`; echo
$COLLECTIONS_TO_CLEAN | egrep --color=always '.*'
278 if [[ "$CLEAN" == "true" ]]; then
279 for collection in ${COLLECTIONS_TO_CLEAN}; do
280 echo nuke $collection
281 ${SOLR}/bin/solr zk rm -r
/solr_${SAFE_DEST}/collections/${collection} -z localhost:2181
282 echo $?
283 done
284 fi
285 # end RTB 2019-09-10
{code}
UPDATE: another detail I discovered as I was rearranging things after the
Hackday... the script expects the newest dir in the work area to be
$CLUSTER_WD. if one introduces new dirs as I did, you'll have to "touch" the
dir you were working from.
was (Author: bunchr):
script works on Mac OS (Mojave) and CentOS 6.
however, on Mac OS, w/ master branch build of Solr – using "-c" option to
harvest the collections results in repeatably *{color:#FF}rebooting{color}*
the Mac! (not running it as root...)
on CentOS 6, after the Solr JVMs have been restarted (and verified w/
CLUSTERSTATUS, LIST) – eventually OS threads are exhausted:
{code:java}
[bunchr@localhost lab]$ ls
bash: fork: retry: Resource temporarily unavailable
bash: fork: retry: Resource temporarily unavailable
bash: fork: retry: Resource temporarily unavailable
bash: fork: retry: Resource temporarily unavailable
:
:
:{code}
...and pretty much have to reboot (further investigations at the *nix level are
warranted) or nuke the JVMs to get the box back under control.
Workaround is to stop solr via script (or kill -9 `pgrep -f start.jar`), and do
a deleteall /solr.../collections/... (whatever needs to be cleaned up). inside
start() after SAFE_DEST is defined:
{code:java}
275 # RTB 2019-09-10
276 echo COLLECTIONS FOUND IN ZK | egrep --color=always '.*'
277 COLLECTIONS_TO_CLEAN=`${SOLR}/bin/solr zk ls
/solr_${SAFE_DEST}/collections -z localhost:2181`; echo
$COLLECTIONS_TO_CLEAN | egrep --color=always '.*'
278 if [[ "$CLEAN" == "true" ]]; then
279 for collection in ${COLLECTIONS_TO_CLEAN}; do
280 echo nuke $collection
281 ${SOLR}/bin/solr zk rm -r
/solr_${SAFE_DEST}/collections/${collection} -z localhost:2181
282 echo $?
283 done
284 fi
285 # end RTB 2019-09-10
{code}
> More Modern cloud dev script
>
>
> Key: SOLR-11492
> URL: https://issues.apache.org/jira/browse/SOLR-11492
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 8.0
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Minor
> Attachments: cloud.sh, cloud.sh, cloud.sh, cloud.sh, cloud.sh,
> cloud.sh
>
>
> Most of the scripts in solr/cloud-dev do things like start using java -jar
> and other similarly ancient techniques. I recently decided I really didn't
> like that it was a pain to setup a cloud to test a patch/feature and that
> often one winds up needing to blow away existing testing so working on more
> than one thing at a time is irritating... so here's a script I wrote, if
> folks like it I'd be happy for it to be included in solr/cloud-dev
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
