You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Juan José Ramos Cassella (JIRA)" <ji...@apache.org> on 2018/05/15 09:41:00 UTC

[jira] [Created] (GEODE-5220) DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes Earlier

Juan José Ramos Cassella created GEODE-5220:
-----------------------------------------------

             Summary: 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


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)