Juan José Ramos Cassella created GEODE-3916:
-----------------------------------------------
Summary: CreateDefinedIndexesCommand ignores failed members if at
least one member succeeds creating the index
Key: GEODE-3916
URL: https://issues.apache.org/jira/browse/GEODE-3916
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Juan José Ramos Cassella
I've found this issue while working on GEODE-3898.
With the current logic some indexes might be correctly created in some members
and fail in others; but the user is never notified about these failures if
there's at least one successful creation.
The problem resides within the following logic:
{code:title=CreateDefinedIndexesCommand.java|borderStyle=solid}
if (!successfulMembers.isEmpty()) {
final InfoResultData infoResult =
ResultBuilder.createInfoResultData();
(...)
result = ResultBuilder.buildResult(infoResult);
} else {
// Group members by the exception thrown.
final ErrorResultData erd =
ResultBuilder.createErrorResultData();
(...)
result = ResultBuilder.buildResult(erd);
}
{code}
*How to Reproduce*
# Start a locator with {{enable-cluster-configuration-enabled=true}}.
# Start two servers with {{enable-cluster-configuration-enabled=true}}.
# Create a sample region: {{gfsh create region --name=TestRegion
--type=REPLICATE}}.
# Create one index: {{create index --name=index1 --expression=value
--region=TestRegion1 --member=host1-server1}}
# Define two indexes: {{gfsh -e "define index --name=index1 --expression=value1
--region=TestRegion1" -e "define index --name=index2 --expression=value2
--region=TestRegion1"}}.
# Created the defined indexes: {{gfsh create defined indexes}}.
The last command will show that the index was successfully created only on the
second server and won't say anything about what happened on the first one;
which can be troublesome for users that want to automate this kind of process:
{code}
Indexes successfully created. Use list indexes to get details.
1. 192.168.1.4(host1-server2:11001)<v1>:1025
{code}
Moreover, the {{list indexes}} command will show that the same index has a
different definition on both servers:
{code}
(3) Executing - list indexes
Member Name | Member ID | Region Path |
Name | Type | Indexed Expression | From Clause | Valid Index
------------- | ----------------------------------------- | ------------ |
------ | ----- | ------------------ | ------------ | -----------
host1-server1 | 192.168.1.4(host1-server1:11002)<v1>:1026 | /TestRegion1 |
index1 | RANGE | value | /TestRegion1 | true
host1-server1 | 192.168.1.4(host1-server1:11002)<v1>:1026 | /TestRegion1 |
index2 | RANGE | value2 | /TestRegion1 | true
host1-server2 | 192.168.1.4(host1-server2:11001)<v1>:1025 | /TestRegion1 |
index1 | RANGE | value1 | /TestRegion1 | true
host1-server2 | 192.168.1.4(host1-server2:11001)<v1>:1025 | /TestRegion1 |
index2 | RANGE | value2 | /TestRegion1 | true
{code}
The command should be able to split the results and report back to the user
which indexes succeeded and which failed, specifying on which members as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
