[
https://issues.apache.org/jira/browse/GEODE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15891083#comment-15891083
]
ASF subversion and git services commented on GEODE-2404:
--------------------------------------------------------
Commit 635d3118177f6cae6b0497097e64bdb7a9aee800 in geode's branch
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=635d311 ]
Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/geode into
develop
* 'develop' of https://git-wip-us.apache.org/repos/asf/geode: (57 commits)
GEODE-2551 Fix code issues found by AppChecker
Revert "GEODE-1887: Now Size api goes through ServerProxy when cache is of
type client and DataPolicy is Empty."
GEODE-2538: Don't deserialize values on the server when getting results
GEODE-2461: remove json4s-ast_2.10 as explicit dependency
GEODE-2547: Interest registration no longer causes a CacheLoader to be invoked
GEODE-2526: Enhance log statement to include ResourceTypeName
GEODE-880 Remove unused classes
GEODE-2460: update dependency versions
GEODE-1995: Removed ReliableMessageQueue, ReliableMessageQueueFactory,
ReliableMessageQueueFactoryImpl and it's usage in the code from
GemfireCacheImpl and DistributedRegion.
GEODE-2550 Improve README and BUILDING
GEODE-2538: Don't invoke a cache loader when fetching values for a lucene
query
GEODE-2404: Added support for destroying lucene indexes
GEODE-2545: NPE during lucene query execution when cache is closing or region
is destroyed
GEODE-2515: Disabling BaseLineAndCompareQueryPerfJUnitTest
GEODE-2142: Removing JSON licence stuff from NOTICE files
GEODE-2142: removing tests so run precheckin
GEODE-2142: final compiling build
GEODE-2142: cyclical dependency in gradle build
GEODE-2142: spotless
GEODE-2142: Refactoring of tests to work with new JSONObject class. Changing
file export to use Base64 encoding.
...
> 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
> 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)
