[ 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)
