geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barry Oglesby (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GEODE-2404) Add API to destroy a region containing lucene indexes
Date Mon, 03 Apr 2017 20:13:42 GMT

     [ https://issues.apache.org/jira/browse/GEODE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Barry Oglesby updated GEODE-2404:
---------------------------------
    Fix Version/s: 1.2.0

> 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: docs, lucene
>            Reporter: Barry Oglesby
>            Assignee: Barry Oglesby
>             Fix For: 1.2.0
>
>         Attachments: DestroyRegionMultipleMembersFunction.java
>
>
> 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)

Mime
View raw message