[
https://issues.apache.org/jira/browse/GEODE-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5220.
---------------------------------------------
Resolution: Fixed
Fix Version/s: 1.7.0
Changes merged into develop by through
[9e8dfb21d661d225fd579a6bccbfed9b4a1ea536|https://github.com/apache/geode/commit/9e8dfb21d661d225fd579a6bccbfed9b4a1ea536].
Setting the Fix Version to 1.7.0, as stated in the [Developer
Workflow|https://cwiki.apache.org/confluence/display/GEODE/Developer+Workflow].
> DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes
> Earlier
> ----------------------------------------------------------------------------------
>
> Key: GEODE-5220
> URL: https://issues.apache.org/jira/browse/GEODE-5220
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions, wan
> Reporter: Juan José Ramos Cassella
> Assignee: Juan José Ramos Cassella
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Attachments: reproducer.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The method {{DistributedRegion.postCreateRegion()}} currently validates that
> the {{gateway-sender}} or {{async-event-queue}} associated with the region
> upon creation (if any) is not of type {{parallel}} as that is not supported
> by regions of type {{REPLICATED}}:
> {code:title=DistributedRegion.java|borderStyle=solid}
> @Override
> public void postCreateRegion() {
> super.postCreateRegion();
> ...
> Set<String> allGatewaySenderIds = getAllGatewaySenderIds();
> if (!allGatewaySenderIds.isEmpty()) {
> for (GatewaySender sender : this.cache.getAllGatewaySenders()) {
> if (sender.isParallel() &&
> allGatewaySenderIds.contains(sender.getId())) {
> // Fix for Bug#51491. Once decided to support this configuration
> we have call
> // addShadowPartitionedRegionForUserRR
> if
> (sender.getId().contains(AsyncEventQueueImpl.ASYNC_EVENT_QUEUE_PREFIX)) {
> throw new AsyncEventQueueConfigurationException(
>
> LocalizedStrings.ParallelAsyncEventQueue_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {
>
> AsyncEventQueueImpl.getAsyncEventQueueIdFromSenderId(sender.getId()),
> this.getFullPath()}));
> }
> throw new GatewaySenderConfigurationException(
>
> LocalizedStrings.ParallelGatewaySender_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {sender.getId(),
> this.getFullPath()}));
> }
> }
> }
> ...
> {code}
> However, the {{gateway-sender}}/{{async-event-queue}} has been associated to
> the region before this last check and the code doesn't catch the
> {{GatewaySenderConfigurationException}} /
> {{AsyncEventQueueConfigurationException}} within that block:
> {code:title=GemFireCacheImpl.java|borderStyle=solid}
> public <K, V> Region<K, V> createVMRegion(String name, RegionAttributes<K, V>
> p_attrs, InternalRegionArguments internalRegionArgs) throws
> RegionExistsException, TimeoutException, IOException, ClassNotFoundException {
> ...
> region.postCreateRegion();
> } catch (RegionExistsException ex) {
> // outside of sync make sure region is initialized to fix bug 37563
> InternalRegion internalRegion = (InternalRegion) ex.getRegion();
> internalRegion.waitOnInitialization(); // don't give out ref until
> initialized
> throw ex;
> }
> ...
> {code}
> This ends up leaving the region unusable but already added to the
> {{GemFireCacheImpl.rootRegions}} field, so the cache itself is left
> inconsistent (could be even worse when the region is also configured as
> persistent).
> No big deal when the user is configuring everything using a {{cache.xml}}
> file as the exception will be propagated and the server startup will fail.
> When using {{gfsh}}, on the other hand, the command {{create region}} reports
> a failure but leaves the region partially created on every single member.
> According to [~dschneider]
> {quote}
> The intent of postCreateRegion is to do things after the region was created.
> This is the wrong place to be doing validation.
> If you look at the super.postCreateRegion that DistributionRegion calls first
> you will see it incs stats and delivers events to others telling them the
> region was created. You really can't undo that well if postCreateRegion
> fails. So I do not think it is a good idea to have postCreateRegion destroy
> the region it created.
> I think the bug here is that gateway validation is in postCreateRegion. This
> validation should be done earlier so that the region creation it self fails
> and postCreateRegion is never called.
> {quote}
> The attached script reproduces the issue both using {{gfsh}} and a
> {{cache.xml}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
