Barry Oglesby created GEODE-2404:
------------------------------------
Summary: Add API to destroy a region containing lucene indexes
Key: GEODE-2404
URL: https://issues.apache.org/jira/browse/GEODE-2404
Project: Geode
Issue Type: New Feature
Components: lucene
Reporter: Barry Oglesby
h2. Description
An application {{Region}} containing {{LuceneIndexes}} should be able to be
destroyed.
There are several options, including:
- Invoke one API to destroy both the application {{Region}} and its
{{LuceneIndexes}}
- Invoke two API:
## destroy the {{LuceneIndexes}}
## destroy application {{Region}} as it is done currently
h3. One API
In this case, we would need a callback on {{LuceneService}} to destroy the
{{LuceneIndexes}} before destroying the application {{Region}} like:
{noformat}
public void beforeDestroyRegion(Region region);
{noformat}
This API would get all the {{LuceneIndexes}} for the application {{Region}},
then destroy each one. See the *Two API* section below for details on
destroying a {{LuceneIndex}}.
Without changes to the way {{PartitionedRegions}} are destroyed, this causes an
issue though.
The current behavior of {{PartitionedRegion destroyRegion}} is to first check
for colocated children. If there are any, the call fails.
There are two options for adding the call to destroy the {{LuceneIndexes}}:
# check for colocated children
# invoke {{LuceneService beforeDestroyRegion}} to remove the {{LuceneIndexes}}
# do the rest of the destroy
<or>
# invoke {{LuceneService beforeDestroyRegion}} to remove the {{LuceneIndexes}}
# check for colocated children
# do the rest of the destroy
Both of these options are problematic in different ways.
In the case of a {{PartitionedRegion}} with {{LuceneIndexes}}, there are
colocated children, so the first option would cause the {{destroyRegion}} call
to fail; the second option would succeed. I don't think the first option should
fail since the colocated children are internal {{Regions}} that the application
knows nothing about.
In the case of a {{PartitionedRegion}} defining {{LuceneIndexes}} and having an
{{AsyncEventQueue}}, there are colocated children, so the first option would
cause the {{destroyRegion}} call to fail. This is ok since one of the children
is an application-known {{AsyncEventQueue}}. The second option would fail in a
bad way. It would first remove the {{LuceneIndexes}}, then fail the colocated
children check, so the {{destroyRegion}} call would fail. In this case, the
application {{Region}} doesn't get destroyed but its {{LuceneIndexes}} do. This
would be bad.
One option would be to look into changing the check for colocated children to
check for application-defined (or not hidden) colocated children. Then the code
would be something like:
# check for application-defined colocated children
# invoke LuceneService beforeDestroyRegion to remove the LuceneIndexes
# do the rest of the destroy
I think this would be ok in both cases.
h3. Two API
The destroy API on {{LuceneIndex}} would be something like:
{noformat}
public void destroy();
{noformat}
Destroying each {{LuceneIndex}} would require:
# destroying the chunk {{Region}}
# destroying the file {{Region}}
# destroying the {{AsyncEventQueue}} which would require:
## retrieving and stopping the {{AsyncEventQueue's}} underlying
{{GatewaySender}} (there probably should be stop API on {{AsyncEventQueue}}
which does this)
## removing the id from the application {{Region's AsyncEventQueue}} ids
## destroying the {{AsyncEventQueue}} (this destroys the underlying
{{GatewaySender}} and removes it from the {{GemFireCacheImpl's}} collection of
{{GatewaySenders}})
## removing the {{AsyncEventQueue}} from the {{GemFireCacheImpl's}} collection
of {{AsyncEventQueues}} (this should be included in the destroy method above)
# removing {{LuceneIndex}} from {{LuceneService's}} map of indexes
I also think the API on {{LuceneService}} should be something like:
{noformat}
public void destroyIndexes(String regionPath);
public void destroyIndex(String indexName, String regionPath);
{noformat}
These methods would get the appropriate {{LuceneIndex(es)}} and invoke destroy
on them. Then they would remove the index(es) from the {{LuceneService's}}
collection of {{LuceneIndexes}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
