[
https://issues.apache.org/jira/browse/SOLR-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14350586#comment-14350586
]
Mike Drob commented on SOLR-7187:
---------------------------------
Yea, I traced the queues through from delete to unload. Based on your comments
and running a few sample tests, it sounds like the difference in implementation
is architectural, which gives me a little confusion to how we name things.
Data dir in HDFS:
{{hdfs://localhost:44036/solr/delete_data_dir/core_node2/data}}
Instance dir in HDFS:
{{/tmp/solr.cloud.hdfs.StressHdfsTest-C14CE921F29EF7F3-001/tempDir-005/delete_data_dir_shard2_replica1}}
Data dir in non-HDFS:
{{/tmp/solr.cloud.CreateDeleteCollectionTest-AD37514288D15339-001/tempDir-003/delete_data_dir_shard1_replica2/data/}}
Instance dir in non-HDFS:
{{/tmp/solr.cloud.CreateDeleteCollectionTest-AD37514288D15339-001/tempDir-003/delete_data_dir_shard1_replica2}}
When we delete the instance dir, we are always looking at a local directory. I
could wire up a patch to delete {{dataDir.getParent()}} when deleting the data
direcotry if we are using HDFS, but that seems fragile. Maybe it makes the most
sense to delete the entire collection dir as a post step, if we determine that
we're on HDFS. My impression is that there is no common collection-wide local
directory for non-HDFS use cases, even when multiple cores are hosted on the
same server, which is why this wasn't seen outside of HDFS.
Is the {{tempDir-003}} part of the path a meaningful directory level or just an
artifact of JUnit structuring; i.e. should we be worrying about deleting it
when we delete a collection (we currently do not)?
> SolrCloud does not fully clean collection after delete
> ------------------------------------------------------
>
> Key: SOLR-7187
> URL: https://issues.apache.org/jira/browse/SOLR-7187
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.10.3
> Reporter: Mike Drob
> Attachments: log.out.gz
>
>
> When I attempt to delete a collection using
> {{/admin/collections?action=DELETE&name=collection1}} if I go into HDFS I
> will still see remnants from the collection. No files, but empty directories
> stick around.
> {noformat}
> [root@solr1 ~]# sudo -u hdfs hdfs dfs -ls -R /solr/collection1
> drwxr-xr-x - solr solr 0 2015-03-03 15:42
> /solr/collection1/core_node1
> drwxr-xr-x - solr solr 0 2015-03-03 15:42
> /solr/collection1/core_node2
> drwxr-xr-x - solr solr 0 2015-03-03 15:42
> /solr/collection1/core_node3
> drwxr-xr-x - solr solr 0 2015-03-03 15:42
> /solr/collection1/core_node4
> drwxr-xr-x - solr solr 0 2015-03-03 15:42
> /solr/collection1/core_node5
> drwxr-xr-x - solr solr 0 2015-03-03 15:42
> /solr/collection1/core_node6
> {noformat}
> (Edit: I had the wrong log portion here originally)
> In the logs, after deleting all the data, I see:
> {noformat}
> 2015-03-03 16:15:14,762 INFO org.apache.solr.servlet.SolrDispatchFilter:
> [admin] webapp=null path=/admin/cores
> params={deleteInstanceDir=true&action=UNLOAD&core=collection1_shard5_replica1&wt=javabin&qt=/admin/cores&deleteDataDir=true&version=2}
> status=0 QTime=362
> 2015-03-03 16:15:14,787 INFO org.apache.solr.common.cloud.ZkStateReader: A
> cluster state change: WatchedEvent state:SyncConnected type:NodeDataChanged
> path:/clusterstate.json, has occurred - updating... (live nodes size: 1)
> 2015-03-03 16:15:14,854 INFO org.apache.solr.cloud.DistributedQueue:
> LatchChildWatcher fired on path: /overseer/queue state: SyncConnected type
> NodeChildrenChanged
> 2015-03-03 16:15:14,879 INFO org.apache.solr.cloud.DistributedQueue:
> LatchChildWatcher fired on path: /overseer/queue state: SyncConnected type
> NodeChildrenChanged
> 2015-03-03 16:15:14,896 INFO org.apache.solr.cloud.DistributedQueue:
> LatchChildWatcher fired on path: /overseer/queue state: SyncConnected type
> NodeChildrenChanged
> 2015-03-03 16:15:14,920 INFO org.apache.solr.cloud.DistributedQueue:
> LatchChildWatcher fired on path: /overseer/queue state: SyncConnected type
> NodeChildrenChanged
> 2015-03-03 16:15:15,151 INFO org.apache.solr.cloud.DistributedQueue:
> LatchChildWatcher fired on path: /overseer/queue state: SyncConnected type
> NodeChildrenChanged
> 2015-03-03 16:15:15,170 INFO org.apache.solr.cloud.DistributedQueue:
> LatchChildWatcher fired on path: /overseer/queue state: SyncConnected type
> NodeChildrenChanged
> 2015-03-03 16:15:15,279 INFO org.apache.solr.common.cloud.ZkStateReader: A
> cluster state change: WatchedEvent state:SyncConnected type:NodeDataChanged
> path:/clusterstate.json, has occurred - updating... (live nodes size: 1)
> 2015-03-03 16:15:15,546 INFO org.apache.solr.cloud.DistributedQueue:
> LatchChildWatcher fired on path:
> /overseer/collection-queue-work/qnr-0000000016 state: SyncConnected type
> NodeDataChanged
> 2015-03-03 16:15:15,562 INFO org.apache.solr.cloud.DistributedQueue:
> LatchChildWatcher fired on path: /overseer/collection-queue-work state:
> SyncConnected type NodeChildrenChanged
> 2015-03-03 16:15:15,562 INFO
> org.apache.solr.cloud.OverseerCollectionProcessor: Overseer Collection
> Processor: Message id:/overseer/collection-queue-work/qn-0000000016 complete,
> response:{success={solr1.example.com:8983_solr={responseHeader={status=0,QTime=207}},solr1.example.com:8983_solr={responseHeader={status=0,QTime=243}},solr1.example.com:8983_solr={responseHeader={status=0,QTime=243}},solr1.example.com:8983_solr={responseHeader={status=0,QTime=342}},solr1.example.com:8983_solr={responseHeader={status=0,QTime=346}},solr1.example.com:8983_solr={responseHeader={status=0,QTime=362}}}}
> {noformat}
> This might be related to SOLR-5023, but I'm not sure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
