[jira] [Commented] (GEODE-3845) local-destroy setting of eviction breaks the consistency of the partition region
[
https://issues.apache.org/jira/browse/GEODE-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260407#comment-16260407
]
Masaki Yamakawa commented on GEODE-3845:
That's good idea to add the destroy option (or distributed-destroy option).
> local-destroy setting of eviction breaks the consistency of the partition
> region
>
>
> Key: GEODE-3845
> URL: https://issues.apache.org/jira/browse/GEODE-3845
> Project: Geode
> Issue Type: Bug
> Components: eviction
>Reporter: Masaki Yamakawa
>
> I use entry-idle-time and eviction together in a partition region that holds
> one redundant copy.
> Details of setting are as follows:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
> {code}
> In this setting, the data held by the cache server is different. Then,
> inconsistent results are returned depending on the server to be connected.
> Eviction of the partition region can only select local-destroy or
> overflow-to-disk. On the other hand, it is written that the expire chapter of
> the document can not use local-destroy, local-invalidate in the partition
> region. Likewise, I think that data inconsistency will occur even with the
> settings like this time.
> Below is the test code:
> https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java
> I think that it is necessary to add a check at the time of region creation or
> write it in the document.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GEODE-3411) Monitor the neighbour JVM using neihbour's member-timeout
[ https://issues.apache.org/jira/browse/GEODE-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravind M updated GEODE-3411: - Description: The idea is able to make critical member to survive in the view for a little longer time than others. But we cannot do with the current suspect mechanism. Now a member can be removed from the view in two cases: one is missing heartbeat and second is missing acknowledgement of message. In the first case ,the final check is done by coordinators member-timeout and in the second case the final check done by suspecting member by its own timeout. So, in these two cases if we manage to suspect the member by the member-timeout of the suspected one in the final check then we can achieve to make a member survive in the view a little longer by configuring a greater member-timeout to that member. was: Now when a member monitor's its neighbor, It uses it's own member timeout to wait and then pass the suspect request to coordinator. But if we do so, while configuring the member timeout of all the member's, we are not sure for how much time that member will be removed from the view as it depends on the member-timeout of the jvm which is monitoring this one. So, if we use neighbor's member-timeout to wait for response instead of its own member-timeout, then we can know for how much time a member will be removed from the view. > Monitor the neighbour JVM using neihbour's member-timeout > - > > Key: GEODE-3411 > URL: https://issues.apache.org/jira/browse/GEODE-3411 > Project: Geode > Issue Type: Wish > Components: membership >Reporter: Aravind M > > The idea is able to make critical member to survive in the view for a little > longer time than others. > But we cannot do with the current suspect mechanism. > Now a member can be removed from the view in two cases: one is missing > heartbeat and second is missing acknowledgement of message. > In the first case ,the final check is done by coordinators member-timeout and > in the second case the final check done by suspecting member by its own > timeout. > So, in these two cases if we manage to suspect the member by the > member-timeout of the suspected one in the final check then we can achieve to > make a member survive in the view a little longer by configuring a greater > member-timeout to that member. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3411) Suspect the member by it's own member-timeout
[ https://issues.apache.org/jira/browse/GEODE-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravind M updated GEODE-3411: - Summary: Suspect the member by it's own member-timeout (was: Monitor the neighbour JVM using neihbour's member-timeout) > Suspect the member by it's own member-timeout > - > > Key: GEODE-3411 > URL: https://issues.apache.org/jira/browse/GEODE-3411 > Project: Geode > Issue Type: Wish > Components: membership >Reporter: Aravind M > > The idea is able to make critical member to survive in the view for a little > longer time than others. > But we cannot do with the current suspect mechanism. > Now a member can be removed from the view in two cases: one is missing > heartbeat and second is missing acknowledgement of message. > In the first case ,the final check is done by coordinators member-timeout and > in the second case the final check done by suspecting member by its own > timeout. > So, in these two cases if we manage to suspect the member by the > member-timeout of the suspected one in the final check then we can achieve to > make a member survive in the view a little longer by configuring a greater > member-timeout to that member. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3411) Suspect a member by suspected member-timeout.
[ https://issues.apache.org/jira/browse/GEODE-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravind M updated GEODE-3411: - Summary: Suspect a member by suspected member-timeout. (was: Suspect the member by it's own member-timeout) > Suspect a member by suspected member-timeout. > - > > Key: GEODE-3411 > URL: https://issues.apache.org/jira/browse/GEODE-3411 > Project: Geode > Issue Type: Wish > Components: membership >Reporter: Aravind M > > The idea is able to make critical member to survive in the view for a little > longer time than others. > But we cannot do with the current suspect mechanism. > Now a member can be removed from the view in two cases: one is missing > heartbeat and second is missing acknowledgement of message. > In the first case ,the final check is done by coordinators member-timeout and > in the second case the final check done by suspecting member by its own > timeout. > So, in these two cases if we manage to suspect the member by the > member-timeout of the suspected one in the final check then we can achieve to > make a member survive in the view a little longer by configuring a greater > member-timeout to that member. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3411) Do Final check based on suspected member-timeout.
[ https://issues.apache.org/jira/browse/GEODE-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aravind M updated GEODE-3411: - Summary: Do Final check based on suspected member-timeout. (was: Suspect a member by suspected member-timeout.) > Do Final check based on suspected member-timeout. > - > > Key: GEODE-3411 > URL: https://issues.apache.org/jira/browse/GEODE-3411 > Project: Geode > Issue Type: Wish > Components: membership >Reporter: Aravind M > > The idea is able to make critical member to survive in the view for a little > longer time than others. > But we cannot do with the current suspect mechanism. > Now a member can be removed from the view in two cases: one is missing > heartbeat and second is missing acknowledgement of message. > In the first case ,the final check is done by coordinators member-timeout and > in the second case the final check done by suspecting member by its own > timeout. > So, in these two cases if we manage to suspect the member by the > member-timeout of the suspected one in the final check then we can achieve to > make a member survive in the view a little longer by configuring a greater > member-timeout to that member. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-2567) gfsh destroy disk-store should be idempotent
[
https://issues.apache.org/jira/browse/GEODE-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260782#comment-16260782
]
ASF subversion and git services commented on GEODE-2567:
Commit 3a63e609136de4196e4ae4d808358b8dfb8b3116 in geode's branch
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a63e60 ]
GEODE-2567: Update AnalyzeSerializables
- This also includes a change for GEODE-3539
> gfsh destroy disk-store should be idempotent
>
>
> Key: GEODE-2567
> URL: https://issues.apache.org/jira/browse/GEODE-2567
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh
>Reporter: Swapnil Bawaskar
>
> Currently, gfsh {{destroy disk-store}} does *not* throw an error when run
> multiple times:
> {{{
> gfsh>destroy disk-store --name=foo
> Member | Result
> -- | ---
> serv1 | Disk store not found on this member
> serv2 | Disk store not found on this member
> }}}
> However, for a uniform user experience, it should. We should then add a
> {{--if-exists}} option to the command to make it idempotent.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3539) Add more test coverage for p2p commands
[ https://issues.apache.org/jira/browse/GEODE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260783#comment-16260783 ] ASF subversion and git services commented on GEODE-3539: Commit 3a63e609136de4196e4ae4d808358b8dfb8b3116 in geode's branch refs/heads/develop from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a63e60 ] GEODE-2567: Update AnalyzeSerializables - This also includes a change for GEODE-3539 > Add more test coverage for p2p commands > --- > > Key: GEODE-3539 > URL: https://issues.apache.org/jira/browse/GEODE-3539 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jinmei Liao > > Add more command tests that would eventually get rid of the legacy tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3962) Use Peer to Peer communication to request cluster configuration
[ https://issues.apache.org/jira/browse/GEODE-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260946#comment-16260946 ] ASF subversion and git services commented on GEODE-3962: Commit 37a897027074d4f160a5f96cd171ac384fa1b6df in geode's branch refs/heads/develop from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=37a8970 ] GEODE-3962: use function call to get cluster configuration from a locator (#1059) * GEODE-3962: use function all to retrieve cluster configuration from a locator > Use Peer to Peer communication to request cluster configuration > --- > > Key: GEODE-3962 > URL: https://issues.apache.org/jira/browse/GEODE-3962 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao > Fix For: 1.4.0 > > > We should not use a TCPClient to request the CC from the locator when a > server is starting up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3962) Use Peer to Peer communication to request cluster configuration
[ https://issues.apache.org/jira/browse/GEODE-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260945#comment-16260945 ] ASF subversion and git services commented on GEODE-3962: Commit 37a897027074d4f160a5f96cd171ac384fa1b6df in geode's branch refs/heads/develop from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=37a8970 ] GEODE-3962: use function call to get cluster configuration from a locator (#1059) * GEODE-3962: use function all to retrieve cluster configuration from a locator > Use Peer to Peer communication to request cluster configuration > --- > > Key: GEODE-3962 > URL: https://issues.apache.org/jira/browse/GEODE-3962 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao > Fix For: 1.4.0 > > > We should not use a TCPClient to request the CC from the locator when a > server is starting up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3962) Use Peer to Peer communication to request cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260944#comment-16260944
]
ASF GitHub Bot commented on GEODE-3962:
---
jinmeiliao closed pull request #1059: GEODE-3962: use function call to get
cluster configuration from a locator
URL: https://github.com/apache/geode/pull/1059
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
b/geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
index 96ee2c9a2c..6640bac4c1 100644
---
a/geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
+++
b/geode-core/src/main/java/org/apache/geode/distributed/internal/ClusterConfigurationService.java
@@ -65,7 +65,6 @@
import org.apache.geode.distributed.DistributedLockService;
import org.apache.geode.distributed.DistributedMember;
import org.apache.geode.distributed.DistributedSystem;
-import org.apache.geode.distributed.LeaseExpiredException;
import org.apache.geode.distributed.internal.locks.DLockService;
import org.apache.geode.internal.cache.InternalCache;
import org.apache.geode.internal.cache.InternalRegionArguments;
@@ -80,7 +79,6 @@
import
org.apache.geode.management.internal.configuration.domain.SharedConfigurationStatus;
import org.apache.geode.management.internal.configuration.domain.XmlEntity;
import
org.apache.geode.management.internal.configuration.functions.UploadJarFunction;
-import
org.apache.geode.management.internal.configuration.messages.ConfigurationRequest;
import
org.apache.geode.management.internal.configuration.messages.ConfigurationResponse;
import
org.apache.geode.management.internal.configuration.messages.SharedConfigurationStatusResponse;
import org.apache.geode.management.internal.configuration.utils.XmlUtils;
@@ -488,39 +486,31 @@ private void persistSecuritySettings(final Region configR
* Creates a ConfigurationResponse based on the configRequest, configuration
response contains the
* requested shared configuration This method locks the
ClusterConfigurationService
*/
- public ConfigurationResponse createConfigurationResponse(final
ConfigurationRequest configRequest)
- throws LeaseExpiredException, IOException {
+ public ConfigurationResponse createConfigurationResponse(Set groups)
throws IOException {
+ConfigurationResponse configResponse = null;
-ConfigurationResponse configResponse = new ConfigurationResponse();
-
-for (int i = 0; i < configRequest.getNumAttempts(); i++) {
- boolean isLocked =
this.sharedConfigLockingService.lock(SHARED_CONFIG_LOCK_NAME, 5000, 5000);
- try {
-if (isLocked) {
- Set groups = configRequest.getGroups();
- groups.add(ClusterConfigurationService.CLUSTER_CONFIG);
- logger.info("Building up configuration response with following
configurations: {}",
- groups);
-
- for (String group : groups) {
-Configuration configuration = getConfiguration(group);
-configResponse.addConfiguration(configuration);
- }
+boolean isLocked =
this.sharedConfigLockingService.lock(SHARED_CONFIG_LOCK_NAME, 5000, 5000);
+try {
+ if (isLocked) {
+configResponse = new ConfigurationResponse();
+groups.add(ClusterConfigurationService.CLUSTER_CONFIG);
+logger.info("Building up configuration response with following
configurations: {}", groups);
+
+for (String group : groups) {
+ Configuration configuration = getConfiguration(group);
+ configResponse.addConfiguration(configuration);
+}
- Map jarNamesToJarBytes =
getAllJarsFromThisLocator(groups);
- String[] jarNames =
jarNamesToJarBytes.keySet().stream().toArray(String[]::new);
- byte[][] jarBytes = jarNamesToJarBytes.values().toArray(new
byte[jarNames.length][]);
+Map jarNamesToJarBytes =
getAllJarsFromThisLocator(groups);
+String[] jarNames =
jarNamesToJarBytes.keySet().stream().toArray(String[]::new);
+byte[][] jarBytes = jarNamesToJarBytes.values().toArray(new
byte[jarNames.length][]);
- configResponse.addJarsToBeDeployed(jarNames, jarBytes);
- configResponse.setFailedToGetSharedConfig(false);
- return configResponse;
-}
- } finally {
-this.sharedConfigLockingService.unlock(SHARED_CONFIG_LOCK_NAME);
+configResponse.addJarsToBeDeployed(jarNames, jarBytes);
+return configResponse;
}
-
+} finally {
+ this.sharedConfigLockingService.unlock(SH
[jira] [Commented] (GEODE-3788) alter async event queue attributes
[
https://issues.apache.org/jira/browse/GEODE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260950#comment-16260950
]
ASF GitHub Bot commented on GEODE-3788:
---
jdeppe-pivotal commented on a change in pull request #1083: GEODE-3788: add
utility methods to get the async event queues in the …
URL: https://github.com/apache/geode/pull/1083#discussion_r152320158
##
File path:
geode-core/src/main/java/org/apache/geode/management/ManagementService.java
##
@@ -216,6 +216,11 @@ public abstract DistributedLockServiceMXBean
getDistributedLockServiceMXBean(
*/
public abstract Set queryMBeanNames(DistributedMember member);
+ /**
+ * Returns the ids of the async event queues on this member
+ */
+ public abstract Set getAsyncEventQueueIds(DistributedMember member);
Review comment:
For consistency with the rest of the methods here, this should probably just
be `getAsyncEventQueueMBeanNames` and return `Set`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> alter async event queue attributes
> --
>
> Key: GEODE-3788
> URL: https://issues.apache.org/jira/browse/GEODE-3788
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh
>Reporter: Swapnil Bawaskar
>
> We should add a new {{alter async-event-queue}} gfsh command that will allow
> users to change the following attributes on the AsyncEventQueue:
> - batch size
> - batch time interval
> - maximum queue memory
> Attributes changed with this command should only be reflected in cluster
> configuration. We will require users to do a rolling re-start of the servers
> for the new settings to take effect.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-1897) Users should be able to configure eviction through gfsh
[
https://issues.apache.org/jira/browse/GEODE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260984#comment-16260984
]
ASF subversion and git services commented on GEODE-1897:
Commit 717fa6bb9ad9abac235d8e2a21ba4c321a83a8d7 in geode's branch
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=717fa6b ]
GEODE-1897: Acceptance test - users should be able to configure eviction
through gfsh
- This closes #1056
> Users should be able to configure eviction through gfsh
> ---
>
> Key: GEODE-1897
> URL: https://issues.apache.org/jira/browse/GEODE-1897
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Karen Smoler Miller
> Fix For: 1.4.0
>
>
> While creating a region in gfsh, users should be able to configure eviction
> for that region.
> All three modes of eviction should be supported:
> 1. Eviction driven by the resource manager:
> {noformat}
> gfsh>create region --name=myRegion --type=REPLICATE --eviction-enabled
> {noformat}
> 2. eviction driven by entry count in the region:
> {noformat}
> gfsh>create region --name=myRegion --type=REPLICATE
> --eviction-entry-count=1000
> {noformat}
> 3. eviction driven by bytes used:
> {noformat}
> gfsh>create region --name=myRegion --type=REPLICATE --eviction-max-memory=100
> (value in megabytes)
> {noformat}
> And also specify the eviction action as
> {noformat}
> --eviction-action=overflow-to-disk or
> --eviction-action=local-destroy
> {noformat}
> and an object sizer, so that users can plug-in custom object sizes as
> {noformat}
> --eviction-object-sizer=my.company.geode.MySizer
> {noformat}
> the sizer should only apply to heap and memory based eviction.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-2563) All destroy commands in gfsh should be idempotent
[
https://issues.apache.org/jira/browse/GEODE-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260985#comment-16260985
]
ASF GitHub Bot commented on GEODE-2563:
---
jdeppe-pivotal closed pull request #1056: GEODE-2563:Added acceptance test
URL: https://github.com/apache/geode/pull/1056
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/ConfigureEvictionThroughGfsh.java
b/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/ConfigureEvictionThroughGfsh.java
new file mode 100644
index 00..61b9a8c913
--- /dev/null
+++
b/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/ConfigureEvictionThroughGfsh.java
@@ -0,0 +1,229 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.management.internal.cli.commands;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.io.File;
+import java.io.IOException;
+
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import org.apache.geode.test.compiler.JarBuilder;
+import org.apache.geode.test.dunit.rules.LocatorServerStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.categories.AcceptanceTest;
+import org.apache.geode.test.junit.rules.gfsh.GfshExecution;
+import org.apache.geode.test.junit.rules.gfsh.GfshRule;
+import org.apache.geode.test.junit.rules.gfsh.GfshScript;
+
+// GEODE-1897 Users should be able to configure eviction through gfsh
+@Category(AcceptanceTest.class)
+public class ConfigureEvictionThroughGfsh {
+
+ @Rule
+ public GfshRule gfsh = new GfshRule();
+
+
+ @Test
+ public void ConfigureEvictionByEntryCount() throws Exception {
+
+GfshExecution execution = GfshScript
+.of("start locator --name=locator", "start server --name=server",
+"create region --name=region1 --eviction-action=local-destroy
--eviction-entry-count=1000 --type=REPLICATE",
+"create region --name=region2 --eviction-action=overflow-to-disk
--eviction-entry-count=1000 --type=REPLICATE",
+"create region --name=region3 --eviction-action=overflow-to-disk
--eviction-entry-count=1000 --type=REPLICATE_PERSISTENT",
+"create region --name=region4 --eviction-action=local-destroy
--eviction-entry-count=1000 --type=LOCAL",
+"create region --name=region5 --eviction-action=overflow-to-disk
--eviction-entry-count=1000 --type=LOCAL")
+.execute(gfsh);
+
+assertThat(execution.getOutputText()).contains("Region \"/region1\"
created on \"server\"");
+assertThat(execution.getOutputText()).contains("Region \"/region2\"
created on \"server\"");
+assertThat(execution.getOutputText()).contains("Region \"/region3\"
created on \"server\"");
+assertThat(execution.getOutputText()).contains("Region \"/region4\"
created on \"server\"");
+assertThat(execution.getOutputText()).contains("Region \"/region5\"
created on \"server\"");
+
+execution = GfshScript
+.of("connect --locator=localhost[10334]",
+"create region --name=region6 --eviction-action=local-destroy
--eviction-entry-count=1000 --type=REPLICATE_PERSISTENT")
+.expectFailure().execute(gfsh);
+assertThat(execution.getOutputText()).contains(
+"ERROR: An Eviction Controller with local destroy eviction action is
incompatible with");
+
+execution = GfshScript
+.of("connect --locator=localhost[10334]", "describe region
--name=region1").execute(gfsh);
+assertThat(execution.getOutputText()).containsPattern("region1")
+.containsPattern("eviction-action\\s+| local-destroy")
+.containsPattern("eviction-maximum-value\\s+ | 1000");
+
+execution = GfshScript
+.of("connect --locator=localhost[10334]",
[jira] [Commented] (GEODE-3781) Users would like PDX to JDBC connector
[ https://issues.apache.org/jira/browse/GEODE-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261001#comment-16261001 ] ASF subversion and git services commented on GEODE-3781: Commit 45e04fb698dc3ea73fae2ac84603baff398252e7 in geode's branch refs/heads/feature/GEODE-3781 from [~nreich] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=45e04fb ] Merge branch 'feature/GEODE-3781' of ssh://github.com/apache/geode into feature/GEODE-3781 > Users would like PDX to JDBC connector > -- > > Key: GEODE-3781 > URL: https://issues.apache.org/jira/browse/GEODE-3781 > Project: Geode > Issue Type: Wish > Components: regions >Reporter: Fred Krone >Assignee: Kirk Lund > > Users would like easy inline caching > This is the epic for the inline caching improvements -- write behind, write > through, read through. > The goal is here to allow users easy mapping of region to table. Either the > user can provide a simple field to column config file and it is injected at > runtime (more flexible) or we use a simple name to name mapping with no > configuration needed. > Feedback 1: "people don't like the idea of every team writing the same kind > of write behind logic again and again" > Feedback 2: "I write a lot of boiler plate code over and over again for this > very thing" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3781) Users would like PDX to JDBC connector
[ https://issues.apache.org/jira/browse/GEODE-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261000#comment-16261000 ] ASF subversion and git services commented on GEODE-3781: Commit 45e04fb698dc3ea73fae2ac84603baff398252e7 in geode's branch refs/heads/feature/GEODE-3781 from [~nreich] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=45e04fb ] Merge branch 'feature/GEODE-3781' of ssh://github.com/apache/geode into feature/GEODE-3781 > Users would like PDX to JDBC connector > -- > > Key: GEODE-3781 > URL: https://issues.apache.org/jira/browse/GEODE-3781 > Project: Geode > Issue Type: Wish > Components: regions >Reporter: Fred Krone >Assignee: Kirk Lund > > Users would like easy inline caching > This is the epic for the inline caching improvements -- write behind, write > through, read through. > The goal is here to allow users easy mapping of region to table. Either the > user can provide a simple field to column config file and it is injected at > runtime (more flexible) or we use a simple name to name mapping with no > configuration needed. > Feedback 1: "people don't like the idea of every team writing the same kind > of write behind logic again and again" > Feedback 2: "I write a lot of boiler plate code over and over again for this > very thing" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-4001) Default value for batch-time-interval of async event queue mismatch between docs and implementation
[ https://issues.apache.org/jira/browse/GEODE-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-4001: -- Assignee: Karen Smoler Miller > Default value for batch-time-interval of async event queue mismatch between > docs and implementation > --- > > Key: GEODE-4001 > URL: https://issues.apache.org/jira/browse/GEODE-4001 > Project: Geode > Issue Type: Bug > Components: client queues, docs >Reporter: Jinmei Liao >Assignee: Karen Smoler Miller > > The document says the the batch-time-interval of the "create > async-event-queue" is 5ms, but testing shows the value of this attribute of > the created async event queue is 1000. > Found these in the code, not sure which one should be good: > In GatewaySender.java: > /** >* The default batch time interval in milliseconds >*/ > public static final int DEFAULT_BATCH_TIME_INTERVAL = 1000; > In AsyncEventQueue.java: > /** >* Represents the maximum time interval that can elapse before a batch is > sent from >* AsyncEventQueue. Default batchTimeInterval is 5 ms. >* >* @return int >*/ > public int getBatchTimeInterval(); -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-4001) Default value for batch-time-interval of async event queue mismatch between docs and implementation
[ https://issues.apache.org/jira/browse/GEODE-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-4001: --- Component/s: docs > Default value for batch-time-interval of async event queue mismatch between > docs and implementation > --- > > Key: GEODE-4001 > URL: https://issues.apache.org/jira/browse/GEODE-4001 > Project: Geode > Issue Type: Bug > Components: client queues, docs >Reporter: Jinmei Liao > > The document says the the batch-time-interval of the "create > async-event-queue" is 5ms, but testing shows the value of this attribute of > the created async event queue is 1000. > Found these in the code, not sure which one should be good: > In GatewaySender.java: > /** >* The default batch time interval in milliseconds >*/ > public static final int DEFAULT_BATCH_TIME_INTERVAL = 1000; > In AsyncEventQueue.java: > /** >* Represents the maximum time interval that can elapse before a batch is > sent from >* AsyncEventQueue. Default batchTimeInterval is 5 ms. >* >* @return int >*/ > public int getBatchTimeInterval(); -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3788) alter async event queue attributes
[
https://issues.apache.org/jira/browse/GEODE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261053#comment-16261053
]
ASF subversion and git services commented on GEODE-3788:
Commit 7d80ee498d9f093084cc21cc8540bf70b68ee434 in geode's branch
refs/heads/develop from [~jinmeiliao]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7d80ee4 ]
GEODE-3788: GfshParserRule enhancement (#1082)
> alter async event queue attributes
> --
>
> Key: GEODE-3788
> URL: https://issues.apache.org/jira/browse/GEODE-3788
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh
>Reporter: Swapnil Bawaskar
>
> We should add a new {{alter async-event-queue}} gfsh command that will allow
> users to change the following attributes on the AsyncEventQueue:
> - batch size
> - batch time interval
> - maximum queue memory
> Attributes changed with this command should only be reflected in cluster
> configuration. We will require users to do a rolling re-start of the servers
> for the new settings to take effect.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3788) alter async event queue attributes
[
https://issues.apache.org/jira/browse/GEODE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261052#comment-16261052
]
ASF GitHub Bot commented on GEODE-3788:
---
jinmeiliao closed pull request #1082: GEODE-3788: GfshParserRule enhancement
URL: https://github.com/apache/geode/pull/1082
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StartLocatorCommandIntegrationTest.java
b/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StartLocatorCommandIntegrationTest.java
index f8cd315f1f..d4dc4e8e57 100644
---
a/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StartLocatorCommandIntegrationTest.java
+++
b/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StartLocatorCommandIntegrationTest.java
@@ -29,7 +29,6 @@
import org.junit.Rule;
import org.junit.Test;
import org.junit.experimental.categories.Category;
-import org.junit.rules.ExpectedException;
import org.mockito.ArgumentCaptor;
import org.mockito.Mockito;
@@ -45,9 +44,6 @@
@Rule
public GfshParserRule commandRule = new GfshParserRule();
- @Rule
- public ExpectedException thrown = ExpectedException.none();
-
private StartLocatorCommand spy;
@Before
@@ -58,7 +54,6 @@ public void before() throws Exception {
@Test
public void startLocatorWorksWithNoOptions() throws Exception {
-thrown.expect(NullPointerException.class);
commandRule.executeCommandWithInstance(spy, "start locator");
ArgumentCaptor gemfirePropertiesCaptor =
ArgumentCaptor.forClass(Properties.class);
@@ -75,7 +70,6 @@ public void
startLocatorRespectsJmxManagerHostnameForClients() throws Exception
String startLocatorCommand = new CommandStringBuilder("start locator")
.addOption(JMX_MANAGER_HOSTNAME_FOR_CLIENTS, FAKE_HOSTNAME).toString();
-thrown.expect(NullPointerException.class);
commandRule.executeCommandWithInstance(spy, startLocatorCommand);
ArgumentCaptor gemfirePropertiesCaptor =
ArgumentCaptor.forClass(Properties.class);
diff --git
a/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StartServerCommandIntegrationTest.java
b/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StartServerCommandIntegrationTest.java
index 92f874993a..1e6b7c2d4d 100644
---
a/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StartServerCommandIntegrationTest.java
+++
b/geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/StartServerCommandIntegrationTest.java
@@ -29,7 +29,6 @@
import org.junit.Rule;
import org.junit.Test;
import org.junit.experimental.categories.Category;
-import org.junit.rules.ExpectedException;
import org.mockito.ArgumentCaptor;
import org.mockito.Mockito;
@@ -45,9 +44,6 @@
@Rule
public GfshParserRule commandRule = new GfshParserRule();
- @Rule
- public ExpectedException thrown = ExpectedException.none();
-
private StartServerCommand spy;
@Before
@@ -58,7 +54,6 @@ public void before() throws Exception {
@Test
public void startServerWorksWithNoOptions() throws Exception {
-thrown.expect(NullPointerException.class);
commandRule.executeCommandWithInstance(spy, "start server");
ArgumentCaptor gemfirePropertiesCaptor =
ArgumentCaptor.forClass(Properties.class);
@@ -75,7 +70,6 @@ public void startServerRespectsJmxManagerHostnameForClients()
throws Exception {
String startServerCommand = new CommandStringBuilder("start server")
.addOption(JMX_MANAGER_HOSTNAME_FOR_CLIENTS, FAKE_HOSTNAME).toString();
-thrown.expect(NullPointerException.class);
commandRule.executeCommandWithInstance(spy, startServerCommand);
ArgumentCaptor gemfirePropertiesCaptor =
ArgumentCaptor.forClass(Properties.class);
diff --git
a/geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandExecutor.java
b/geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandExecutor.java
index d4f52187b8..5a165ea05f 100755
---
a/geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandExecutor.java
+++
b/geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandExecutor.java
@@ -34,9 +34,15 @@
public class CommandExecutor {
private Logger logger = LogService.getLogger();
+ // used by the product
public Object execute(ParseResult parseResult) {
+return execute(null, parseResult);
+ }
+
+ // used by the GfshParserRule to pass in a mock command
+ public Object execute(
[jira] [Updated] (GEODE-4000) Add 1.3.0 version to geode-old-versions gradle file
[ https://issues.apache.org/jira/browse/GEODE-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge updated GEODE-4000: - Summary: Add 1.3.0 version to geode-old-versions gradle file (was: Add 1.3.0 version to geode-ol-version gradle file) > Add 1.3.0 version to geode-old-versions gradle file > --- > > Key: GEODE-4000 > URL: https://issues.apache.org/jira/browse/GEODE-4000 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: nabarun >Assignee: nabarun > > Adding 1.3.0 version tag in geode-old-versions for backward compatibility and > rolling upgrade tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3063) Improve docs on default string-based partition resolver
[ https://issues.apache.org/jira/browse/GEODE-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261215#comment-16261215 ] ASF GitHub Bot commented on GEODE-3063: --- davebarnes97 commented on a change in pull request #1077: GEODE-3063 partition resolver doc revisions URL: https://github.com/apache/geode/pull/1077#discussion_r152356310 ## File path: geode-docs/developing/partitioned_regions/colocating_partitioned_region_data.html.md.erb ## @@ -19,27 +19,19 @@ See the License for the specific language governing permissions and limitations under the License. --> -By default, <%=vars.product_name%> allocates the data locations for a partitioned region independent of the data locations for any other partitioned region. You can change this policy for any group of partitioned regions, so that cross-region, related data is all hosted by the same member. This colocation speeds queries and other operations that access data from the regions. +By default, <%=vars.product_name%> allocates the data locations for a partitioned region independent of the data locations for any other partitioned region. You can change this policy for any group of partitioned regions, so that cross-region, related data is all hosted by the same member. +Colocation is required for some operations, Review comment: This paragraph also appears in overview_custom_partitioning_and_data_colocation.html, so you need to repeat this edit in that file, too. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve docs on default string-based partition resolver > --- > > Key: GEODE-3063 > URL: https://issues.apache.org/jira/browse/GEODE-3063 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > The new default partition resolver at > org.apache.geode.cache.util.StringPrefixPartitionResolver > needs more detailed documentation. > - An example of a string specifying a key in a region operation when this > partition resolver is used. > - What happens if the string specifying a key doesn't have a '|' delimiter. > - An example of using this partition resolver to colocate two regions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3063) Improve docs on default string-based partition resolver
[ https://issues.apache.org/jira/browse/GEODE-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261214#comment-16261214 ] ASF GitHub Bot commented on GEODE-3063: --- davebarnes97 commented on a change in pull request #1077: GEODE-3063 partition resolver doc revisions URL: https://github.com/apache/geode/pull/1077#discussion_r152360010 ## File path: geode-docs/developing/partitioned_regions/using_custom_partition_resolvers.html.md.erb ## @@ -19,47 +19,64 @@ See the License for the specific language governing permissions and limitations under the License. --> -By default, <%=vars.product_name%> partitions each data entry into a bucket using a hashing policy on the key. Additionally, the physical location of the key-value pair is abstracted away from the application. You can change these policies for a partitioned region. You can provide your own data partitioning resolver and you can additionally specify which members host which data buckets. +By default, <%=vars.product_name%> partitions each data entry into a bucket using a hashing policy on the key. +Additionally, the physical location of the key-value pair +is abstracted away from the application. +You can change these policies for a partitioned region by providing +your own partition resolver. +The partitioning can go further with a fixed-partition resolver +that specifies which members host which data buckets. **Note:** -If you are colocating data between regions and custom partitioning the data in the regions, all colocated regions must use the same custom partitioning mechanism. See [Colocate Data from Different Partitioned Regions](colocating_partitioned_region_data.html#colocating_partitioned_region_data). +If you are both colocating region data and custom partitioning, +all colocated regions must use the same custom partitioning mechanism. +See [Colocate Data from Different Partitioned Regions](colocating_partitioned_region_data.html#colocating_partitioned_region_data). - +The two steps of implementing the interface +and configuring the regions are described. +These steps differ based on which partition resolver is used. Review comment: Consider active voice here, maybe something like: To custom-partition your region data, follow two steps: - implement the interface - configure the regions These steps differ based on which partition resolver you use. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve docs on default string-based partition resolver > --- > > Key: GEODE-3063 > URL: https://issues.apache.org/jira/browse/GEODE-3063 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > The new default partition resolver at > org.apache.geode.cache.util.StringPrefixPartitionResolver > needs more detailed documentation. > - An example of a string specifying a key in a region operation when this > partition resolver is used. > - What happens if the string specifying a key doesn't have a '|' delimiter. > - An example of using this partition resolver to colocate two regions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-4002) User Guide: Consolidate cache element descriptions
Dave Barnes created GEODE-4002: -- Summary: User Guide: Consolidate cache element descriptions Key: GEODE-4002 URL: https://issues.apache.org/jira/browse/GEODE-4002 Project: Geode Issue Type: Improvement Components: docs Reporter: Dave Barnes The Element Reference is implemented as two largely redundant files. Consolidate into one file. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-4002) User Guide: Consolidate cache element descriptions
[ https://issues.apache.org/jira/browse/GEODE-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-4002: --- Description: The Element Reference is implemented as two largely redundant files. This creates multiple paths to apparently identical, but duplicate, targets and confuses navigation. Consolidate into one file, fix up embedded references, update left-side subnav. (was: The Element Reference is implemented as two largely redundant files. Consolidate into one file.) > User Guide: Consolidate cache element descriptions > -- > > Key: GEODE-4002 > URL: https://issues.apache.org/jira/browse/GEODE-4002 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes > > The Element Reference is implemented as two largely redundant files. > This creates multiple paths to apparently identical, but duplicate, targets > and confuses navigation. Consolidate into one file, fix up embedded > references, update left-side subnav. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-4002) User Guide: Consolidate cache element descriptions
[ https://issues.apache.org/jira/browse/GEODE-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-4002: -- Assignee: Dave Barnes > User Guide: Consolidate cache element descriptions > -- > > Key: GEODE-4002 > URL: https://issues.apache.org/jira/browse/GEODE-4002 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes > > The Element Reference is implemented as two largely redundant files. > This creates multiple paths to apparently identical, but duplicate, targets > and confuses navigation. Consolidate into one file, fix up embedded > references, update left-side subnav. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-4001) Default value for batch-time-interval of async event queue mismatch between docs and implementation
[ https://issues.apache.org/jira/browse/GEODE-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261268#comment-16261268 ] Jason Huynh commented on GEODE-4001: It looks like the default for aeq is 5ms and for gateway senders is 1000ms > Default value for batch-time-interval of async event queue mismatch between > docs and implementation > --- > > Key: GEODE-4001 > URL: https://issues.apache.org/jira/browse/GEODE-4001 > Project: Geode > Issue Type: Bug > Components: client queues, docs >Reporter: Jinmei Liao >Assignee: Karen Smoler Miller > > The document says the the batch-time-interval of the "create > async-event-queue" is 5ms, but testing shows the value of this attribute of > the created async event queue is 1000. > Found these in the code, not sure which one should be good: > In GatewaySender.java: > /** >* The default batch time interval in milliseconds >*/ > public static final int DEFAULT_BATCH_TIME_INTERVAL = 1000; > In AsyncEventQueue.java: > /** >* Represents the maximum time interval that can elapse before a batch is > sent from >* AsyncEventQueue. Default batchTimeInterval is 5 ms. >* >* @return int >*/ > public int getBatchTimeInterval(); -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-4001) Default value for batch-time-interval of async event queue mismatch between docs and implementation
[ https://issues.apache.org/jira/browse/GEODE-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261289#comment-16261289 ] Karen Smoler Miller commented on GEODE-4001: I have verified that the batch-time-interval default is 5msec for async event queues. However, it is 1000msec for gateway senders. The docs are correct for both. Therefore, I'm resolving this ticket without changes. > Default value for batch-time-interval of async event queue mismatch between > docs and implementation > --- > > Key: GEODE-4001 > URL: https://issues.apache.org/jira/browse/GEODE-4001 > Project: Geode > Issue Type: Bug > Components: client queues, docs >Reporter: Jinmei Liao >Assignee: Karen Smoler Miller > > The document says the the batch-time-interval of the "create > async-event-queue" is 5ms, but testing shows the value of this attribute of > the created async event queue is 1000. > Found these in the code, not sure which one should be good: > In GatewaySender.java: > /** >* The default batch time interval in milliseconds >*/ > public static final int DEFAULT_BATCH_TIME_INTERVAL = 1000; > In AsyncEventQueue.java: > /** >* Represents the maximum time interval that can elapse before a batch is > sent from >* AsyncEventQueue. Default batchTimeInterval is 5 ms. >* >* @return int >*/ > public int getBatchTimeInterval(); -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3937) Fix NPE when executing removeFromDisk
[ https://issues.apache.org/jira/browse/GEODE-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261309#comment-16261309 ] ASF GitHub Bot commented on GEODE-3937: --- jhuynh1 commented on issue #1002: GEODE-3937:Fix NPE when executing removeFromDisk URL: https://github.com/apache/geode/pull/1002#issuecomment-345806099 Hi There are a few things going on in this PR… First it looks like you are attempting to add a lot of test code to clear a bucket region queue, this in turn ends up with an NPE thrown in DiskEntry. However, Geode does not currently support clearing the bucket region queue and so this PR introduces some “test” product code. The regression test then calls this “test” code to do the clear. The NPE is then thrown. The NPE itself looks like it would be a product issue, however it turns out that the remove you have attempted to call on the bucketRegion is not the correct remove when it comes to a bucketRegionQueue. What should have been called is destroyKey from the bucket region queue. Whenever clear is added to the product, it would have to handle this special case. The fix to ignore the null in DiskEntry should not be added at this time. I don’t think we should be adding this product code or the related “test” code. It is hiliting a problem that does not currently exist in Geode. The NPE is due to invalid test code. here is are the entry that is removed when removing from a BucketRegionQueue: [vm4] mapDestroy:EntryEventImpl[op=DESTROY;region=/__PR/_B__ln__PARALLEL__GATEWAY__SENDER__QUEUE_0;key=100;oldValue=null;newValue=null;callbackArg=null;originRemote=false;originMember=10.118.20.91(30103):32773;id=EventIDid=18bytes;threadID=2;sequenceID=0]] Compared to the entry the test code attempts to remove: [vm4] mapDestroy:EntryEventImpl[op=DESTROY;region=/ln_PARALLEL_GATEWAY_SENDER_QUEUE;key=100;oldValue=null;newValue=null;callbackArg=null;originRemote=false;originMember=10.118.20.91(30117):32773;id=EventIDid=18bytes;threadID=1;sequenceID=51]] The BucketRegionQueue explicitly sets itself as the region to remove from, whereas the remove that was called in the test code does not do this. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix NPE when executing removeFromDisk > -- > > Key: GEODE-3937 > URL: https://issues.apache.org/jira/browse/GEODE-3937 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: dinesh akhand >Priority: Trivial > > While executing the test case or clearQueueTestOnly method. we can see > exception > [vm4] java.lang.NullPointerException > [vm4] at > org.apache.geode.internal.cache.entries.DiskEntry$Helper.removeFromDisk(DiskEntry.java:1519) > [vm4] at > org.apache.geode.internal.cache.entries.AbstractOplogDiskRegionEntry.removePhase1(AbstractOplogDiskRegionEntry.java:50) > [vm4] at > org.apache.geode.internal.cache.entries.AbstractRegionEntry.destroy(AbstractRegionEntry.java:914) > [vm4] at > org.apache.geode.internal.cache.AbstractRegionMap.destroyEntry(AbstractRegionMap.java:3100) > [vm4] at > org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1429) > [vm4] at > org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6465) > [vm4] at > org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6439) > [vm4] at > org.apache.geode.internal.cache.BucketRegion.basicDestroy(BucketRegion.java:1167) > [vm4] at > org.apache.geode.internal.cache.AbstractBucketRegionQueue.basicDestroy(AbstractBucketRegionQueue.java:352) > [vm4] at > org.apache.geode.internal.cache.BucketRegionQueue.basicDestroy(BucketRegionQueue.java:366) > [vm4] at > org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1101) > [vm4] at > org.apache.geode.internal.cache.DistributedRegion.validatedDestroy(DistributedRegion.java:942) > [vm4] at > org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1086) > [vm4] at > org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:315) > [vm4] at > org.apache.geode.internal.cache.LocalRegion.remove(LocalRegion.java:8870) > [vm4] at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.clearPartitionedRegion(ParallelGatewaySenderQueue.java:1820) > [vm4] at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySend
[jira] [Resolved] (GEODE-4001) Default value for batch-time-interval of async event queue mismatch between docs and implementation
[ https://issues.apache.org/jira/browse/GEODE-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-4001. Resolution: Not A Problem > Default value for batch-time-interval of async event queue mismatch between > docs and implementation > --- > > Key: GEODE-4001 > URL: https://issues.apache.org/jira/browse/GEODE-4001 > Project: Geode > Issue Type: Bug > Components: client queues, docs >Reporter: Jinmei Liao >Assignee: Karen Smoler Miller > > The document says the the batch-time-interval of the "create > async-event-queue" is 5ms, but testing shows the value of this attribute of > the created async event queue is 1000. > Found these in the code, not sure which one should be good: > In GatewaySender.java: > /** >* The default batch time interval in milliseconds >*/ > public static final int DEFAULT_BATCH_TIME_INTERVAL = 1000; > In AsyncEventQueue.java: > /** >* Represents the maximum time interval that can elapse before a batch is > sent from >* AsyncEventQueue. Default batchTimeInterval is 5 ms. >* >* @return int >*/ > public int getBatchTimeInterval(); -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3788) alter async event queue attributes
[
https://issues.apache.org/jira/browse/GEODE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261451#comment-16261451
]
ASF GitHub Bot commented on GEODE-3788:
---
jinmeiliao commented on issue #1083: GEODE-3788: add utility methods to get the
async event queues in the …
URL: https://github.com/apache/geode/pull/1083#issuecomment-346154296
precheckin green
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> alter async event queue attributes
> --
>
> Key: GEODE-3788
> URL: https://issues.apache.org/jira/browse/GEODE-3788
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh
>Reporter: Swapnil Bawaskar
>
> We should add a new {{alter async-event-queue}} gfsh command that will allow
> users to change the following attributes on the AsyncEventQueue:
> - batch size
> - batch time interval
> - maximum queue memory
> Attributes changed with this command should only be reflected in cluster
> configuration. We will require users to do a rolling re-start of the servers
> for the new settings to take effect.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3788) alter async event queue attributes
[
https://issues.apache.org/jira/browse/GEODE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261467#comment-16261467
]
ASF GitHub Bot commented on GEODE-3788:
---
jinmeiliao closed pull request #1083: GEODE-3788: add utility methods to get
the async event queues in the …
URL: https://github.com/apache/geode/pull/1083
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/geode-core/src/main/java/org/apache/geode/management/ManagementService.java
b/geode-core/src/main/java/org/apache/geode/management/ManagementService.java
index 887b04abed..eb2e80855c 100755
---
a/geode-core/src/main/java/org/apache/geode/management/ManagementService.java
+++
b/geode-core/src/main/java/org/apache/geode/management/ManagementService.java
@@ -216,6 +216,11 @@ public abstract DistributedLockServiceMXBean
getDistributedLockServiceMXBean(
*/
public abstract Set queryMBeanNames(DistributedMember member);
+ /**
+ * Returns the ids of the async event queues on this member
+ */
+ public abstract Set
getAsyncEventQueueMBeanNames(DistributedMember member);
+
/**
* Returns an instance of an MBean. This is a reference to the MBean
instance and not a
* {@link ObjectInstance}.
diff --git
a/geode-core/src/main/java/org/apache/geode/management/internal/MBeanJMXAdapter.java
b/geode-core/src/main/java/org/apache/geode/management/internal/MBeanJMXAdapter.java
index 467e3d18fe..f3c0fe3466 100644
---
a/geode-core/src/main/java/org/apache/geode/management/internal/MBeanJMXAdapter.java
+++
b/geode-core/src/main/java/org/apache/geode/management/internal/MBeanJMXAdapter.java
@@ -483,11 +483,6 @@ public static ObjectName
getAsyncEventQueueMBeanName(DistributedMember member, S
getMemberNameOrId(member;
}
- public static ObjectName getAsyncEventQueueMBeanName(String member, String
queueId) {
-return
getObjectName((MessageFormat.format(OBJECTNAME__ASYNCEVENTQUEUE_MXBEAN, queueId,
-makeCompliantName(member;
- }
-
public static ObjectName getDistributedRegionMbeanName(String regionPath) {
return
getObjectName((MessageFormat.format(OBJECTNAME__DISTRIBUTEDREGION_MXBEAN,
makeCompliantRegionPath(regionPath;
diff --git
a/geode-core/src/main/java/org/apache/geode/management/internal/SystemManagementService.java
b/geode-core/src/main/java/org/apache/geode/management/internal/SystemManagementService.java
index 60615db12c..8f2c9c70c6 100755
---
a/geode-core/src/main/java/org/apache/geode/management/internal/SystemManagementService.java
+++
b/geode-core/src/main/java/org/apache/geode/management/internal/SystemManagementService.java
@@ -18,6 +18,7 @@
import java.util.List;
import java.util.Set;
import java.util.concurrent.CopyOnWriteArrayList;
+import java.util.stream.Collectors;
import javax.management.Notification;
import javax.management.ObjectName;
@@ -357,6 +358,13 @@ public MemberMXBean getMemberMXBean() {
}
}
+ @Override
+ public Set getAsyncEventQueueMBeanNames(DistributedMember
member) {
+Set mBeanNames = this.queryMBeanNames(member);
+return mBeanNames.stream().filter(x ->
"AsyncEventQueue".equals(x.getKeyProperty("service")))
+.collect(Collectors.toSet());
+ }
+
@Override
public ObjectName registerMBean(Object object, ObjectName objectName) {
verifyManagementService();
diff --git
a/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
b/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
index 02eb8b81a6..8ad2282797 100755
---
a/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
+++
b/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
@@ -60,6 +60,7 @@
import org.apache.geode.management.ManagementService;
import org.apache.geode.management.cli.Result;
import org.apache.geode.management.internal.MBeanJMXAdapter;
+import org.apache.geode.management.internal.SystemManagementService;
import org.apache.geode.management.internal.cli.exceptions.UserErrorException;
import org.apache.geode.management.internal.cli.i18n.CliStrings;
import org.apache.geode.management.internal.cli.result.ResultBuilder;
@@ -406,6 +407,20 @@ public static Result getFunctionResult(ResultCollector rc, String commandN
return result;
}
+ public static Set
getMembersWithAsyncEventQueue(InternalCache cache,
+ String queueId) {
+Set members = findMembers(null, null);
+return members.stream().filter(m -> getAsyncEventQueueIds(cache,
m).contains(queueId))
+.collect(Collectors.toSet());
+ }
+
+ public static Set getAsyncEventQueueIds(InternalCache cache,
DistributedMember
[jira] [Commented] (GEODE-3788) alter async event queue attributes
[
https://issues.apache.org/jira/browse/GEODE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261468#comment-16261468
]
ASF subversion and git services commented on GEODE-3788:
Commit 10dc0a212eb9d9813e13fd02e8436ac9d8b0ae37 in geode's branch
refs/heads/develop from [~jinmeiliao]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=10dc0a2 ]
GEODE-3788: add utility methods to get the async event queues in the … (#1083)
* GEODE-3788: add utility methods to get the async event queues in the running
cluster
> alter async event queue attributes
> --
>
> Key: GEODE-3788
> URL: https://issues.apache.org/jira/browse/GEODE-3788
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh
>Reporter: Swapnil Bawaskar
>
> We should add a new {{alter async-event-queue}} gfsh command that will allow
> users to change the following attributes on the AsyncEventQueue:
> - batch size
> - batch time interval
> - maximum queue memory
> Attributes changed with this command should only be reflected in cluster
> configuration. We will require users to do a rolling re-start of the servers
> for the new settings to take effect.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3788) alter async event queue attributes
[
https://issues.apache.org/jira/browse/GEODE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261469#comment-16261469
]
ASF subversion and git services commented on GEODE-3788:
Commit 10dc0a212eb9d9813e13fd02e8436ac9d8b0ae37 in geode's branch
refs/heads/develop from [~jinmeiliao]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=10dc0a2 ]
GEODE-3788: add utility methods to get the async event queues in the … (#1083)
* GEODE-3788: add utility methods to get the async event queues in the running
cluster
> alter async event queue attributes
> --
>
> Key: GEODE-3788
> URL: https://issues.apache.org/jira/browse/GEODE-3788
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh
>Reporter: Swapnil Bawaskar
>
> We should add a new {{alter async-event-queue}} gfsh command that will allow
> users to change the following attributes on the AsyncEventQueue:
> - batch size
> - batch time interval
> - maximum queue memory
> Attributes changed with this command should only be reflected in cluster
> configuration. We will require users to do a rolling re-start of the servers
> for the new settings to take effect.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (GEODE-3946) Attempting to connect an older version gfsh to a newer version JMX manager should fail
[
https://issues.apache.org/jira/browse/GEODE-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-3946:
---
Assignee: Patrick Rhomberg
> Attempting to connect an older version gfsh to a newer version JMX manager
> should fail
> --
>
> Key: GEODE-3946
> URL: https://issues.apache.org/jira/browse/GEODE-3946
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Patrick Rhomberg
>Priority: Trivial
>
> Currently, an older version of gfsh can connect to a newer version JMX
> manager, but when a command is invoked, it'll fail with a cryptic message.
> An example is:
> 9.1.1 JMX manager
> 9.0.3 gfsh
> Attempting to execute a query with this scenario logs a 'Could not parse
> command string' message:
> {noformat}
> gfsh>query --query='SELECT sauce FROM /data' --interactive=true
> Could not parse command string. query --query='SELECT sauce FROM /data'
> --interactive=true --step-name=SELECT_EXEC
> {noformat}
> Instead, gfsh should fail at connect time with an
> {{IncompatibleVersionException}} or something similar.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3788) alter async event queue attributes
[
https://issues.apache.org/jira/browse/GEODE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261482#comment-16261482
]
ASF GitHub Bot commented on GEODE-3788:
---
jinmeiliao opened a new pull request #1084: GEODE-3788: add alter
async-event-queue command and tests
URL: https://github.com/apache/geode/pull/1084
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, you check travis-ci for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> alter async event queue attributes
> --
>
> Key: GEODE-3788
> URL: https://issues.apache.org/jira/browse/GEODE-3788
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh
>Reporter: Swapnil Bawaskar
>
> We should add a new {{alter async-event-queue}} gfsh command that will allow
> users to change the following attributes on the AsyncEventQueue:
> - batch size
> - batch time interval
> - maximum queue memory
> Attributes changed with this command should only be reflected in cluster
> configuration. We will require users to do a rolling re-start of the servers
> for the new settings to take effect.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GEODE-4003) User Guide: Update Element Hierarchy
Dave Barnes created GEODE-4003: -- Summary: User Guide: Update Element Hierarchy Key: GEODE-4003 URL: https://issues.apache.org/jira/browse/GEODE-4003 Project: Geode Issue Type: Improvement Components: docs Reporter: Dave Barnes The Element Hierarcy (../reference/topics/cache-elements-list.html) needs updating. It contains deprecated elements such as and , and is missing some elements, such as . -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-4004) callers of EntryEventImpl.getRawOldValue that will serialize the result need to make sure it is not Token.NOT_AVAILABLE
Darrel Schneider created GEODE-4004: --- Summary: callers of EntryEventImpl.getRawOldValue that will serialize the result need to make sure it is not Token.NOT_AVAILABLE Key: GEODE-4004 URL: https://issues.apache.org/jira/browse/GEODE-4004 Project: Geode Issue Type: Bug Components: regions Reporter: Darrel Schneider EntryEventImpl.getRawOldValue may return Token.NOT_AVAILABLE. Callers of this method that will serialize what it returns need to check for NOT_AVAILABLE and serialize something else (usually null). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-4004) callers of EntryEventImpl.getRawOldValue that will serialize the result need to make sure it is not Token.NOT_AVAILABLE
[ https://issues.apache.org/jira/browse/GEODE-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-4004: --- Assignee: Darrel Schneider > callers of EntryEventImpl.getRawOldValue that will serialize the result need > to make sure it is not Token.NOT_AVAILABLE > --- > > Key: GEODE-4004 > URL: https://issues.apache.org/jira/browse/GEODE-4004 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > > EntryEventImpl.getRawOldValue may return Token.NOT_AVAILABLE. > Callers of this method that will serialize what it returns need to check for > NOT_AVAILABLE and serialize something else (usually null). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-4002) User Guide: Consolidate cache element descriptions
[ https://issues.apache.org/jira/browse/GEODE-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261644#comment-16261644 ] ASF GitHub Bot commented on GEODE-4002: --- davebarnes97 opened a new pull request #1085: GEODE-4002 User Guide: Consolidate cache element descriptions URL: https://github.com/apache/geode/pull/1085 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User Guide: Consolidate cache element descriptions > -- > > Key: GEODE-4002 > URL: https://issues.apache.org/jira/browse/GEODE-4002 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes > > The Element Reference is implemented as two largely redundant files. > This creates multiple paths to apparently identical, but duplicate, targets > and confuses navigation. Consolidate into one file, fix up embedded > references, update left-side subnav. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-4004) callers of EntryEventImpl.getRawOldValue that will serialize the result need to make sure it is not Token.NOT_AVAILABLE
[ https://issues.apache.org/jira/browse/GEODE-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-4004. - Resolution: Not A Problem Code inspection shows that this issue was already fixed. > callers of EntryEventImpl.getRawOldValue that will serialize the result need > to make sure it is not Token.NOT_AVAILABLE > --- > > Key: GEODE-4004 > URL: https://issues.apache.org/jira/browse/GEODE-4004 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > > EntryEventImpl.getRawOldValue may return Token.NOT_AVAILABLE. > Callers of this method that will serialize what it returns need to check for > NOT_AVAILABLE and serialize something else (usually null). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-4005) CommandOverHttpDUnitTest is causing lots of tests to be run a second time
Bruce Schuchardt created GEODE-4005: --- Summary: CommandOverHttpDUnitTest is causing lots of tests to be run a second time Key: GEODE-4005 URL: https://issues.apache.org/jira/browse/GEODE-4005 Project: Geode Issue Type: Task Components: management Reporter: Bruce Schuchardt This is a test-suite class that is causing 13 other test classes to be run a second time. We should remove this class and create a gradle task to run the tests based on their category, like we do with client/server, membership and other categories. The tests gathered by this class are run by themselves and then again when this class is executed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-4006) NPE in RemoteGfManagerAgent.removeMember
Anilkumar Gingade created GEODE-4006: Summary: NPE in RemoteGfManagerAgent.removeMember Key: GEODE-4006 URL: https://issues.apache.org/jira/browse/GEODE-4006 Project: Geode Issue Type: Bug Components: management Reporter: Anilkumar Gingade Fix For: 1.4.0 There could be possibility that NPE is thrown in RemoteGfManagerAgent.removeMember at org.apache.geode.internal.admin.remote.RemoteGfManagerAgent.removeMember(RemoteGfManagerAgent.java:678) at org.apache.geode.internal.admin.remote.RemoteGfManagerAgent$MyMembershipListener.memberDeparted(RemoteGfManagerAgent.java:1398) at org.apache.geode.distributed.internal.DistributionManager$MemberDepartedEvent.handleEvent(DistributionManager.java:4520) at org.apache.geode.distributed.internal.DistributionManager$MemberEvent.handleEvent(DistributionManager.java:4449) at org.apache.geode.distributed.internal.DistributionManager$MemberEvent.handleEvent(DistributionManager.java:4439) at org.apache.geode.distributed.internal.DistributionManager.handleMemberEvent(DistributionManager.java:2423) at org.apache.geode.distributed.internal.DistributionManager$MemberEventInvoker.run(DistributionManager.java:2452) Sorry, don't have much artifacts or test to reproduce. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-1703) CI failure: PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId fails assertion: Region not created within30000
[
https://issues.apache.org/jira/browse/GEODE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261676#comment-16261676
]
Anilkumar Gingade commented on GEODE-1703:
--
One more issue with the test:
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest >
testCrashDuringPreparePersistentId FAILED
java.lang.RuntimeException: java.lang.IllegalStateException: Disk store
PersistentRecoveryOrderDUnitTest_testCrashDuringPreparePersistentIdRegion not
found
at
org.apache.geode.internal.cache.persistence.PersistentReplicatedTestBase._createPersistentRegion(PersistentReplicatedTestBase.java:186)
at
org.apache.geode.internal.cache.persistence.PersistentReplicatedTestBase.createPersistentRegion(PersistentReplicatedTestBase.java:172)
at
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId(PersistentRecoveryOrderDUnitTest.java:1325)
Caused by:
java.lang.IllegalStateException: Disk store
PersistentRecoveryOrderDUnitTest_testCrashDuringPreparePersistentIdRegion not
found
> CI failure:
> PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId fails
> assertion: Region not created within3
> ---
>
> Key: GEODE-1703
> URL: https://issues.apache.org/jira/browse/GEODE-1703
> Project: Geode
> Issue Type: Bug
> Components: regions, tests
>Reporter: Kirk Lund
> Labels: CI, flaky
>
> {noformat}
> :geode-core:distributedTest
> com.gemstone.gemfire.internal.cache.persistence.PersistentRecoveryOrderDUnitTest
> > testCrashDuringPreparePersistentId FAILED
> java.lang.AssertionError: Region not created within3
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.internal.cache.persistence.PersistentReplicatedTestBase._createPersistentRegion(PersistentReplicatedTestBase.java:179)
> at
> com.gemstone.gemfire.internal.cache.persistence.PersistentReplicatedTestBase.createPersistentRegion(PersistentReplicatedTestBase.java:172)
> at
> com.gemstone.gemfire.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId(PersistentRecoveryOrderDUnitTest.java:1344)
> 7429 tests completed, 1 failed, 587 skipped
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3063) Improve docs on default string-based partition resolver
[ https://issues.apache.org/jira/browse/GEODE-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261677#comment-16261677 ] ASF GitHub Bot commented on GEODE-3063: --- karensmolermiller commented on a change in pull request #1077: GEODE-3063 partition resolver doc revisions URL: https://github.com/apache/geode/pull/1077#discussion_r152431888 ## File path: geode-docs/developing/partitioned_regions/using_custom_partition_resolvers.html.md.erb ## @@ -19,47 +19,64 @@ See the License for the specific language governing permissions and limitations under the License. --> -By default, <%=vars.product_name%> partitions each data entry into a bucket using a hashing policy on the key. Additionally, the physical location of the key-value pair is abstracted away from the application. You can change these policies for a partitioned region. You can provide your own data partitioning resolver and you can additionally specify which members host which data buckets. +By default, <%=vars.product_name%> partitions each data entry into a bucket using a hashing policy on the key. +Additionally, the physical location of the key-value pair +is abstracted away from the application. +You can change these policies for a partitioned region by providing +your own partition resolver. +The partitioning can go further with a fixed-partition resolver +that specifies which members host which data buckets. **Note:** -If you are colocating data between regions and custom partitioning the data in the regions, all colocated regions must use the same custom partitioning mechanism. See [Colocate Data from Different Partitioned Regions](colocating_partitioned_region_data.html#colocating_partitioned_region_data). +If you are both colocating region data and custom partitioning, +all colocated regions must use the same custom partitioning mechanism. +See [Colocate Data from Different Partitioned Regions](colocating_partitioned_region_data.html#colocating_partitioned_region_data). - +The two steps of implementing the interface +and configuring the regions are described. +These steps differ based on which partition resolver is used. Review comment: Thanks Dave! I made these changes. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve docs on default string-based partition resolver > --- > > Key: GEODE-3063 > URL: https://issues.apache.org/jira/browse/GEODE-3063 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > The new default partition resolver at > org.apache.geode.cache.util.StringPrefixPartitionResolver > needs more detailed documentation. > - An example of a string specifying a key in a region operation when this > partition resolver is used. > - What happens if the string specifying a key doesn't have a '|' delimiter. > - An example of using this partition resolver to colocate two regions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3038) A server process shuts down quietly when path to cache.xml is incorrect
[
https://issues.apache.org/jira/browse/GEODE-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261699#comment-16261699
]
ASF GitHub Bot commented on GEODE-3038:
---
agingade closed pull request #677: GEODE-3038: A server process shuts down
quietly when path to cache.xml is incorrect
URL: https://github.com/apache/geode/pull/677
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
b/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
index f176d22065..89d8b467c5 100755
---
a/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
+++
b/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
@@ -1208,6 +1208,9 @@ private void initialize() {
this.system.getConfig());
initializeDeclarativeCache();
completedCacheXml = true;
+} catch (RuntimeException e) {
+ logger.error("Cache initialization failed because: " + e.toString()); //
fix GEODE-3038
+ throw e;
} finally {
if (!completedCacheXml) {
// so initializeDeclarativeCache threw an exception
diff --git
a/geode-core/src/test/java/org/apache/geode/cache30/CacheXmlNotFoundRegressionTest.java
b/geode-core/src/test/java/org/apache/geode/cache30/CacheXmlNotFoundRegressionTest.java
new file mode 100644
index 00..dc0d26a977
--- /dev/null
+++
b/geode-core/src/test/java/org/apache/geode/cache30/CacheXmlNotFoundRegressionTest.java
@@ -0,0 +1,76 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.cache30;
+
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.CacheXmlException;
+import org.apache.geode.distributed.ConfigurationProperties;
+import org.apache.geode.test.junit.categories.IntegrationTest;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+
+import java.io.File;
+import java.util.Properties;
+import java.util.Scanner;
+
+import static junit.framework.TestCase.assertTrue;
+import static org.junit.Assert.fail;
+
+@Category(IntegrationTest.class)
+public class CacheXmlNotFoundRegressionTest {
+
+ /**
+ * unit test for https://issues.apache.org/jira/browse/GEODE-3038";>GEODE-3038 Tests
+ * that an error about missing cache-xml file is indeed printed in the text
log file. The test
+ * {@link CacheXml66DUnitTest#testNonExistentFile()} is supposed to test the
same, but is not
+ * enough. It only checks for an CacheXmlException exception to be thrown.
Also in that test a log
+ * is printed into STDOUT, and we do see our error there, but that is not
the case when we work
+ * with the real text log, specified via "log-file" param.
+ */
+ @Test
+ public void testCacheXmlNotFoundInRealLog() throws Exception {
+
+String CACHE_SERVER_LOG = "cacheXmlNotFoundUnitTest.log";
+Properties props = new Properties();
+props.put(ConfigurationProperties.MCAST_PORT, "0");
+props.put(ConfigurationProperties.LOG_FILE, CACHE_SERVER_LOG);
+props.put(ConfigurationProperties.CACHE_XML_FILE,
"non-existing-cache-xml");
+
+CacheFactory factory = new CacheFactory(props);
+
+String errorMessage = "";
+
+try {
+ factory.create();
+ fail("Should have thrown a CacheXmlException");
+} catch (CacheXmlException e) {
+ errorMessage = e.toString();
+}
+
+// looking for an error in the text log file
+Scanner scanner = new Scanner(new File(CACHE_SERVER_LOG));
+
+boolean found = false;
+while (scanner.hasNextLine() && !found) {
+ found = scanner.nextLine().contains(errorMessage);
+}
+scanner.close();
+assertTrue("there should be a line about cache-xml-not-found in a log
file", found);
+
+// deleting a log file
+File logFile = new File(CACHE_SERVER_LOG);
+logFile.delete();
+ }
+}
-
[jira] [Commented] (GEODE-3038) A server process shuts down quietly when path to cache.xml is incorrect
[ https://issues.apache.org/jira/browse/GEODE-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261700#comment-16261700 ] ASF subversion and git services commented on GEODE-3038: Commit f429e9a7eb5bad1ddb2b5eca81228887d87028b3 in geode's branch refs/heads/develop from [~Neighbour] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f429e9a ] GEODE-3038: A server process shuts down quietly when path to cache.xml is incorrect (#677) Exception is thrown and logged when cache.xml is not found during cache creation > A server process shuts down quietly when path to cache.xml is incorrect > --- > > Key: GEODE-3038 > URL: https://issues.apache.org/jira/browse/GEODE-3038 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Anton Mironenko >Priority: Minor > > Geode version: 1.1.1, 1.3.0 (latest develop snapshot) > If I start a server with incorrect path to Server.xml, it shuts down quietly > without any message in the log. > An expected behavior would be the error message "Server.xml not found in the > path [...], shutting down" > Here are the steps to reproduce, please use GEODE-3003 for zip files. > Test preparation: > - > Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip" > 1) unzip "geode-host1.zip" into some folder on your first host > 2) in start-locator.sh change the IPs of locators to the values of your host1 > and host2 > "--locators=10.50.3.38[20236],10.50.3.14[20236]" > 3) in start-server.sh > "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to > the values of your host1 and host2 > 4) do the bullets 1)-4) for host2, the folder where you unzip the file should > be the same as on the first host > Test running: > --- > 0) change start-server.sh so that the path to Server.xml is wrong > cache-xml-file=$SERVERXML_DIR/Server.xml > -> > cache-xml-file=$SERVERXML_DIR/Server_.xml > 1) run ./start-locator.sh on host1 > 2) after some pause run ./start-server > 3) observe the server started and immediately stopped, > 4) observe in the server logs, server1/cacheserver.log: > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] Received > cluster configuration from the locator > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] > *** > Configuration for 'cluster' > > Jar files to deployed > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] Requesting > cluster configuration > [info 2017/06/06 18:32:05.143 MSK host1-server-1 tid=0x1] Got response > with jars: > [info 2017/06/06 18:32:05.209 MSK host1-server-1 tid=0x1] Initializing > region _monitoringRegion_10.50.3.381025 > [info 2017/06/06 18:32:05.222 MSK host1-server-1 tid=0x1] Region > _monitoringRegion_10.50.3.381025 requesting initial image from > 10.50.3.38(host1-locator-0-20236:27511:locator):1024 > [info 2017/06/06 18:32:05.227 MSK host1-server-1 tid=0x1] > _monitoringRegion_10.50.3.381025 is done getting image from > 10.50.3.38(host1-locator-0-20236:27511:locator):1024. isDeltaGII is > false > [info 2017/06/06 18:32:05.228 MSK host1-server-1 tid=0x1] > Initialization of region _monitoringRegion_10.50.3.381025 completed > [info 2017/06/06 18:32:05.812 MSK host1-server-1 tid=0x1] > GemFireCache[id = 2117642238; isClosing = true; isShutDownAll = false; > created = Tue Jun 06 18:32:05 MSK 2017; server = false; copyOnRead = false; > lockLease = 120; lockTimeout = 60]: Now closing. > [info 2017/06/06 18:32:05.855 MSK host1-server-1 tid=0x1] Shutting > down DistributionManager 10.50.3.38(host1-server-1:27773):1025. > [info 2017/06/06 18:32:05.961 MSK host1-server-1 tid=0x1] Now closing > distribution for 10.50.3.38(host1-server-1:27773):1025 > [info 2017/06/06 18:32:05.962 MSK host1-server-1 tid=0x1] Stopping > membership services > [info 2017/06/06 18:32:05.964 MSK host1-server-1 Server thread 0> tid=0x1d] GMSHealthMonitor server thread exiting > [info 2017/06/06 18:32:05.964 MSK host1-server-1 tid=0x1] > GMSHealthMonitor server socket is closed in stopServices(). > [info 2017/06/06 18:32:05.968 MSK host1-server-1 tid=0x1] > GMSHealthMonitor serverSocketExecutor is terminated > [info 2017/06/06 18:32:05.974 MSK host1-server-1 tid=0x1] > DistributionManager stopped in 119ms. > [info 2017/06/06 18:32:05.974 MSK host1-server-1 tid=0x1] Marking > DistributionManager 10.50.3.38(host1-server-1:27773):1025 as closed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3038) A server process shuts down quietly when path to cache.xml is incorrect
[ https://issues.apache.org/jira/browse/GEODE-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261701#comment-16261701 ] ASF GitHub Bot commented on GEODE-3038: --- agingade commented on issue #677: GEODE-3038: A server process shuts down quietly when path to cache.xml is incorrect URL: https://github.com/apache/geode/pull/677#issuecomment-346200020 @anton-mironenko Thanks for submitting the patch. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > A server process shuts down quietly when path to cache.xml is incorrect > --- > > Key: GEODE-3038 > URL: https://issues.apache.org/jira/browse/GEODE-3038 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Anton Mironenko >Priority: Minor > > Geode version: 1.1.1, 1.3.0 (latest develop snapshot) > If I start a server with incorrect path to Server.xml, it shuts down quietly > without any message in the log. > An expected behavior would be the error message "Server.xml not found in the > path [...], shutting down" > Here are the steps to reproduce, please use GEODE-3003 for zip files. > Test preparation: > - > Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip" > 1) unzip "geode-host1.zip" into some folder on your first host > 2) in start-locator.sh change the IPs of locators to the values of your host1 > and host2 > "--locators=10.50.3.38[20236],10.50.3.14[20236]" > 3) in start-server.sh > "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to > the values of your host1 and host2 > 4) do the bullets 1)-4) for host2, the folder where you unzip the file should > be the same as on the first host > Test running: > --- > 0) change start-server.sh so that the path to Server.xml is wrong > cache-xml-file=$SERVERXML_DIR/Server.xml > -> > cache-xml-file=$SERVERXML_DIR/Server_.xml > 1) run ./start-locator.sh on host1 > 2) after some pause run ./start-server > 3) observe the server started and immediately stopped, > 4) observe in the server logs, server1/cacheserver.log: > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] Received > cluster configuration from the locator > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] > *** > Configuration for 'cluster' > > Jar files to deployed > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] Requesting > cluster configuration > [info 2017/06/06 18:32:05.143 MSK host1-server-1 tid=0x1] Got response > with jars: > [info 2017/06/06 18:32:05.209 MSK host1-server-1 tid=0x1] Initializing > region _monitoringRegion_10.50.3.381025 > [info 2017/06/06 18:32:05.222 MSK host1-server-1 tid=0x1] Region > _monitoringRegion_10.50.3.381025 requesting initial image from > 10.50.3.38(host1-locator-0-20236:27511:locator):1024 > [info 2017/06/06 18:32:05.227 MSK host1-server-1 tid=0x1] > _monitoringRegion_10.50.3.381025 is done getting image from > 10.50.3.38(host1-locator-0-20236:27511:locator):1024. isDeltaGII is > false > [info 2017/06/06 18:32:05.228 MSK host1-server-1 tid=0x1] > Initialization of region _monitoringRegion_10.50.3.381025 completed > [info 2017/06/06 18:32:05.812 MSK host1-server-1 tid=0x1] > GemFireCache[id = 2117642238; isClosing = true; isShutDownAll = false; > created = Tue Jun 06 18:32:05 MSK 2017; server = false; copyOnRead = false; > lockLease = 120; lockTimeout = 60]: Now closing. > [info 2017/06/06 18:32:05.855 MSK host1-server-1 tid=0x1] Shutting > down DistributionManager 10.50.3.38(host1-server-1:27773):1025. > [info 2017/06/06 18:32:05.961 MSK host1-server-1 tid=0x1] Now closing > distribution for 10.50.3.38(host1-server-1:27773):1025 > [info 2017/06/06 18:32:05.962 MSK host1-server-1 tid=0x1] Stopping > membership services > [info 2017/06/06 18:32:05.964 MSK host1-server-1 Server thread 0> tid=0x1d] GMSHealthMonitor server thread exiting > [info 2017/06/06 18:32:05.964 MSK host1-server-1 tid=0x1] > GMSHealthMonitor server socket is closed in stopServices(). > [info 2017/06/06 18:32:05.968 MSK host1-server-1 tid=0x1] > GMSHealthMonitor serverSocketExecutor is terminated > [info 2017/06/06 18:32:05.974 MSK host1-server-1 tid=0x1] > DistributionManager stopped in 119ms. > [info 2017/06/06 18:32:05.974 MSK host1-server-1 tid=0x1] Marking > DistributionManager 10.50.3.38(host1-server-1:27773):1025 as closed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (GEODE-3038) A server process shuts down quietly when path to cache.xml is incorrect
[ https://issues.apache.org/jira/browse/GEODE-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade resolved GEODE-3038. -- Resolution: Fixed Fix Version/s: 1.4.0 > A server process shuts down quietly when path to cache.xml is incorrect > --- > > Key: GEODE-3038 > URL: https://issues.apache.org/jira/browse/GEODE-3038 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Anton Mironenko >Priority: Minor > Fix For: 1.4.0 > > > Geode version: 1.1.1, 1.3.0 (latest develop snapshot) > If I start a server with incorrect path to Server.xml, it shuts down quietly > without any message in the log. > An expected behavior would be the error message "Server.xml not found in the > path [...], shutting down" > Here are the steps to reproduce, please use GEODE-3003 for zip files. > Test preparation: > - > Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip" > 1) unzip "geode-host1.zip" into some folder on your first host > 2) in start-locator.sh change the IPs of locators to the values of your host1 > and host2 > "--locators=10.50.3.38[20236],10.50.3.14[20236]" > 3) in start-server.sh > "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to > the values of your host1 and host2 > 4) do the bullets 1)-4) for host2, the folder where you unzip the file should > be the same as on the first host > Test running: > --- > 0) change start-server.sh so that the path to Server.xml is wrong > cache-xml-file=$SERVERXML_DIR/Server.xml > -> > cache-xml-file=$SERVERXML_DIR/Server_.xml > 1) run ./start-locator.sh on host1 > 2) after some pause run ./start-server > 3) observe the server started and immediately stopped, > 4) observe in the server logs, server1/cacheserver.log: > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] Received > cluster configuration from the locator > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] > *** > Configuration for 'cluster' > > Jar files to deployed > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] Requesting > cluster configuration > [info 2017/06/06 18:32:05.143 MSK host1-server-1 tid=0x1] Got response > with jars: > [info 2017/06/06 18:32:05.209 MSK host1-server-1 tid=0x1] Initializing > region _monitoringRegion_10.50.3.381025 > [info 2017/06/06 18:32:05.222 MSK host1-server-1 tid=0x1] Region > _monitoringRegion_10.50.3.381025 requesting initial image from > 10.50.3.38(host1-locator-0-20236:27511:locator):1024 > [info 2017/06/06 18:32:05.227 MSK host1-server-1 tid=0x1] > _monitoringRegion_10.50.3.381025 is done getting image from > 10.50.3.38(host1-locator-0-20236:27511:locator):1024. isDeltaGII is > false > [info 2017/06/06 18:32:05.228 MSK host1-server-1 tid=0x1] > Initialization of region _monitoringRegion_10.50.3.381025 completed > [info 2017/06/06 18:32:05.812 MSK host1-server-1 tid=0x1] > GemFireCache[id = 2117642238; isClosing = true; isShutDownAll = false; > created = Tue Jun 06 18:32:05 MSK 2017; server = false; copyOnRead = false; > lockLease = 120; lockTimeout = 60]: Now closing. > [info 2017/06/06 18:32:05.855 MSK host1-server-1 tid=0x1] Shutting > down DistributionManager 10.50.3.38(host1-server-1:27773):1025. > [info 2017/06/06 18:32:05.961 MSK host1-server-1 tid=0x1] Now closing > distribution for 10.50.3.38(host1-server-1:27773):1025 > [info 2017/06/06 18:32:05.962 MSK host1-server-1 tid=0x1] Stopping > membership services > [info 2017/06/06 18:32:05.964 MSK host1-server-1 Server thread 0> tid=0x1d] GMSHealthMonitor server thread exiting > [info 2017/06/06 18:32:05.964 MSK host1-server-1 tid=0x1] > GMSHealthMonitor server socket is closed in stopServices(). > [info 2017/06/06 18:32:05.968 MSK host1-server-1 tid=0x1] > GMSHealthMonitor serverSocketExecutor is terminated > [info 2017/06/06 18:32:05.974 MSK host1-server-1 tid=0x1] > DistributionManager stopped in 119ms. > [info 2017/06/06 18:32:05.974 MSK host1-server-1 tid=0x1] Marking > DistributionManager 10.50.3.38(host1-server-1:27773):1025 as closed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3038) A server process shuts down quietly when path to cache.xml is incorrect
[ https://issues.apache.org/jira/browse/GEODE-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261758#comment-16261758 ] ASF subversion and git services commented on GEODE-3038: Commit 013b0616c9dc6da471e08f8a954c187ca08f60c4 in geode's branch refs/heads/develop from [~agingade] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=013b061 ] GEODE-3038: Run Spotless > A server process shuts down quietly when path to cache.xml is incorrect > --- > > Key: GEODE-3038 > URL: https://issues.apache.org/jira/browse/GEODE-3038 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Anton Mironenko >Priority: Minor > Fix For: 1.4.0 > > > Geode version: 1.1.1, 1.3.0 (latest develop snapshot) > If I start a server with incorrect path to Server.xml, it shuts down quietly > without any message in the log. > An expected behavior would be the error message "Server.xml not found in the > path [...], shutting down" > Here are the steps to reproduce, please use GEODE-3003 for zip files. > Test preparation: > - > Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip" > 1) unzip "geode-host1.zip" into some folder on your first host > 2) in start-locator.sh change the IPs of locators to the values of your host1 > and host2 > "--locators=10.50.3.38[20236],10.50.3.14[20236]" > 3) in start-server.sh > "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to > the values of your host1 and host2 > 4) do the bullets 1)-4) for host2, the folder where you unzip the file should > be the same as on the first host > Test running: > --- > 0) change start-server.sh so that the path to Server.xml is wrong > cache-xml-file=$SERVERXML_DIR/Server.xml > -> > cache-xml-file=$SERVERXML_DIR/Server_.xml > 1) run ./start-locator.sh on host1 > 2) after some pause run ./start-server > 3) observe the server started and immediately stopped, > 4) observe in the server logs, server1/cacheserver.log: > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] Received > cluster configuration from the locator > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] > *** > Configuration for 'cluster' > > Jar files to deployed > [info 2017/06/06 18:32:05.141 MSK host1-server-1 tid=0x1] Requesting > cluster configuration > [info 2017/06/06 18:32:05.143 MSK host1-server-1 tid=0x1] Got response > with jars: > [info 2017/06/06 18:32:05.209 MSK host1-server-1 tid=0x1] Initializing > region _monitoringRegion_10.50.3.381025 > [info 2017/06/06 18:32:05.222 MSK host1-server-1 tid=0x1] Region > _monitoringRegion_10.50.3.381025 requesting initial image from > 10.50.3.38(host1-locator-0-20236:27511:locator):1024 > [info 2017/06/06 18:32:05.227 MSK host1-server-1 tid=0x1] > _monitoringRegion_10.50.3.381025 is done getting image from > 10.50.3.38(host1-locator-0-20236:27511:locator):1024. isDeltaGII is > false > [info 2017/06/06 18:32:05.228 MSK host1-server-1 tid=0x1] > Initialization of region _monitoringRegion_10.50.3.381025 completed > [info 2017/06/06 18:32:05.812 MSK host1-server-1 tid=0x1] > GemFireCache[id = 2117642238; isClosing = true; isShutDownAll = false; > created = Tue Jun 06 18:32:05 MSK 2017; server = false; copyOnRead = false; > lockLease = 120; lockTimeout = 60]: Now closing. > [info 2017/06/06 18:32:05.855 MSK host1-server-1 tid=0x1] Shutting > down DistributionManager 10.50.3.38(host1-server-1:27773):1025. > [info 2017/06/06 18:32:05.961 MSK host1-server-1 tid=0x1] Now closing > distribution for 10.50.3.38(host1-server-1:27773):1025 > [info 2017/06/06 18:32:05.962 MSK host1-server-1 tid=0x1] Stopping > membership services > [info 2017/06/06 18:32:05.964 MSK host1-server-1 Server thread 0> tid=0x1d] GMSHealthMonitor server thread exiting > [info 2017/06/06 18:32:05.964 MSK host1-server-1 tid=0x1] > GMSHealthMonitor server socket is closed in stopServices(). > [info 2017/06/06 18:32:05.968 MSK host1-server-1 tid=0x1] > GMSHealthMonitor serverSocketExecutor is terminated > [info 2017/06/06 18:32:05.974 MSK host1-server-1 tid=0x1] > DistributionManager stopped in 119ms. > [info 2017/06/06 18:32:05.974 MSK host1-server-1 tid=0x1] Marking > DistributionManager 10.50.3.38(host1-server-1:27773):1025 as closed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-4007) Authentication failures/bad handshake should close the socket from the server side
Brian Rowe created GEODE-4007: - Summary: Authentication failures/bad handshake should close the socket from the server side Key: GEODE-4007 URL: https://issues.apache.org/jira/browse/GEODE-4007 Project: Geode Issue Type: Bug Components: client/server Reporter: Brian Rowe Ensure after failed auth/handshake the server (after sending error response) closes the socket and cleans up. While going over the code together, it looks like maybe authentication errors simply leave the socket in a state where it is expecting another authentication request. It might be better to close the socket from the server side for various error conditions like a failed handshake or authentication. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3781) Users would like PDX to JDBC connector
[ https://issues.apache.org/jira/browse/GEODE-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-3781: -- Component/s: docs > Users would like PDX to JDBC connector > -- > > Key: GEODE-3781 > URL: https://issues.apache.org/jira/browse/GEODE-3781 > Project: Geode > Issue Type: Wish > Components: docs, regions >Reporter: Fred Krone >Assignee: Kirk Lund > > Users would like easy inline caching > This is the epic for the inline caching improvements -- write behind, write > through, read through. > The goal is here to allow users easy mapping of region to table. Either the > user can provide a simple field to column config file and it is injected at > runtime (more flexible) or we use a simple name to name mapping with no > configuration needed. > Feedback 1: "people don't like the idea of every team writing the same kind > of write behind logic again and again" > Feedback 2: "I write a lot of boiler plate code over and over again for this > very thing" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3967) if put hits concurrent modification exception should still notify serial gateway sender
[ https://issues.apache.org/jira/browse/GEODE-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262091#comment-16262091 ] ASF subversion and git services commented on GEODE-3967: Commit e0bbd415763842b6621866e359b7d106838b2323 in geode's branch refs/heads/feature/GEM-883 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e0bbd41 ] GEODE-3967: add to secondary event isConcurrencyConflict > if put hits concurrent modification exception should still notify serial > gateway sender > --- > > Key: GEODE-3967 > URL: https://issues.apache.org/jira/browse/GEODE-3967 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: xiaojian zhou >Assignee: xiaojian zhou > > In serial gateway sender, the event arrives at secondary will be put into > unprocessedMap and wait for event from primary queue to distribute over, then > remove it from the unprocessedMap. > If the put at primary member (member with primary queue) failed with CME, the > event in unprocessedMap will never be removed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
