[jira] [Commented] (GEODE-8786) INFO command hit/miss ratios should match native Redis
[
https://issues.apache.org/jira/browse/GEODE-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259731#comment-17259731
]
ASF GitHub Bot commented on GEODE-8786:
---
jdeppe-pivotal commented on a change in pull request #5875:
URL: https://github.com/apache/geode/pull/5875#discussion_r552236162
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractHitsMissesIntegrationTest.java
##
@@ -286,90 +306,312 @@ public void testHscan() {
runCommandAndAssertHitsAndMisses("hash", (k, v) -> jedis.hscan(k, v));
}
+ @Test
+ public void testHMSet() {
+Map info = getInfo(jedis);
+Long currentHits = Long.parseLong(info.get(HITS));
+Long currentMisses = Long.parseLong(info.get(MISSES));
+
+Map map = new HashMap<>();
+map.put("key1", "value1");
+map.put("key2", "value2");
+
+jedis.hmset("key", map);
Review comment:
This could also just end up being a call to
`runCommandAndAssertNoStatUpdates`
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractHitsMissesIntegrationTest.java
##
@@ -286,90 +306,312 @@ public void testHscan() {
runCommandAndAssertHitsAndMisses("hash", (k, v) -> jedis.hscan(k, v));
}
+ @Test
+ public void testHMSet() {
+Map info = getInfo(jedis);
+Long currentHits = Long.parseLong(info.get(HITS));
+Long currentMisses = Long.parseLong(info.get(MISSES));
+
+Map map = new HashMap<>();
+map.put("key1", "value1");
+map.put("key2", "value2");
+
+jedis.hmset("key", map);
+
+info = getInfo(jedis);
+
+assertThat(info.get(HITS)).isEqualTo(String.valueOf(currentHits));
+assertThat(info.get(MISSES)).isEqualTo(String.valueOf(currentMisses));
+ }
+
+ // Connection related commands ---
+
+ // TODO auth needs some setup. manually verified that auth does not change
hit/miss stats
+ // if that changes we'll need to come back to this test
+ @Ignore
+ @Test
+ public void testAuth() {
Review comment:
I don't think we need tests for these 3 commands since they don't deal
with keys at all and don't even manipulate any data.
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/data/CommandHelper.java
##
@@ -137,37 +140,49 @@ private RedisString checkStringType(RedisData redisData,
boolean ignoreTypeMisma
return (RedisString) redisData;
}
- RedisString getRedisString(ByteArrayWrapper key) {
+ RedisString getRedisString(ByteArrayWrapper key, boolean updateStats) {
RedisData redisData = getRedisData(key, NULL_REDIS_STRING);
-if (redisData == NULL_REDIS_STRING) {
- redisStats.incKeyspaceMisses();
-} else {
- redisStats.incKeyspaceHits();
+if (updateStats) {
+ if (redisData == NULL_REDIS_STRING) {
+redisStats.incKeyspaceMisses();
+ } else {
+redisStats.incKeyspaceHits();
+ }
}
return checkStringType(redisData, false);
}
- RedisString getRedisStringIgnoringType(ByteArrayWrapper key) {
+ RedisString getRedisStringIgnoringType(ByteArrayWrapper key, boolean
updateStats) {
RedisData redisData = getRedisData(key, NULL_REDIS_STRING);
-if (redisData == NULL_REDIS_STRING) {
- redisStats.incKeyspaceMisses();
-} else {
- redisStats.incKeyspaceHits();
+if (updateStats) {
+ if (redisData == NULL_REDIS_STRING) {
+redisStats.incKeyspaceMisses();
+ } else {
+redisStats.incKeyspaceHits();
+ }
}
+
return checkStringType(redisData, true);
}
- RedisString setRedisString(ByteArrayWrapper key, ByteArrayWrapper value) {
+ RedisString setRedisString(ByteArrayWrapper key, ByteArrayWrapper value,
boolean updateStats) {
Review comment:
It looks like this method is only ever called with `updateStats ==
false` so that parameter can be removed. Since it's also a method that is
mutating data it should never be updating the hits/misses stats.
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractHitsMissesIntegrationTest.java
##
@@ -286,90 +306,312 @@ public void testHscan() {
runCommandAndAssertHitsAndMisses("hash", (k, v) -> jedis.hscan(k, v));
}
+ @Test
+ public void testHMSet() {
+Map info = getInfo(jedis);
+Long currentHits = Long.parseLong(info.get(HITS));
+Long currentMisses = Long.parseLong(info.get(MISSES));
+
+Map map = new HashMap<>();
+map.put("key1", "value1");
+map.put("key2", "value2");
+
+jedis.hmset("key", map);
+
+info = getInfo(jedis);
+
+assertThat(info.get(HITS)).isEqualTo(String.valueOf(currentHits));
+assertThat(info.get(MISSES)).isEqualTo(String.valueOf(currentMisses));
+ }
+
+ // Connection related commands ---
+
+ // TODO au
[jira] [Commented] (GEODE-8786) INFO command hit/miss ratios should match native Redis
[
https://issues.apache.org/jira/browse/GEODE-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259748#comment-17259748
]
ASF GitHub Bot commented on GEODE-8786:
---
jdeppe-pivotal commented on a change in pull request #5875:
URL: https://github.com/apache/geode/pull/5875#discussion_r552652990
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/data/RedisSetCommandsFunctionExecutor.java
##
@@ -37,18 +37,22 @@ public RedisSetCommandsFunctionExecutor(
super(helper);
}
- private RedisSet getRedisSet(ByteArrayWrapper key) {
-return helper.getRedisSet(key);
+ private RedisSet getRedisSet(ByteArrayWrapper key, boolean updateStats) {
Review comment:
This is probably a nit, but for consistency can this class be consistent
with the other `*FunctionExecutor`s and either introduce an overloaded
`getRedisSet` which updates stats. Or remove the other classes' duplicate
`getRedisSet` and just have one method.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> INFO command hit/miss ratios should match native Redis
> --
>
> Key: GEODE-8786
> URL: https://issues.apache.org/jira/browse/GEODE-8786
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Priority: Major
> Labels: pull-request-available
>
> Current hit/miss ratios for Geode Redis stats do not match those for native
> Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8248) Member hangs waiting for missing disk-stores after gfsh shutdown
[
https://issues.apache.org/jira/browse/GEODE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259786#comment-17259786
]
Anilkumar Gingade commented on GEODE-8248:
--
The product is behaving as expected; based on the action performed by Gfsh.
When shutdown is executed from gfsh; it does shutdown on each member instead of
shutdown-all.
In order to have the behavior as mentioned in this issue; the gfsh has to call
shutdown-all.
> Member hangs waiting for missing disk-stores after gfsh shutdown
>
>
> Key: GEODE-8248
> URL: https://issues.apache.org/jira/browse/GEODE-8248
> Project: Geode
> Issue Type: Bug
> Components: gfsh, persistence
>Reporter: Juan Ramos
>Priority: Major
> Attachments: temporal.zip
>
>
> Let’s say I have 2 servers with a simple {{REPLICATE_PERSISTENT}} region and
> I stop both using the {{gfsh shutdown}} command.
> According to the
> [documentation|https://geode.apache.org/docs/guide/112/managing/disk_storage/starting_system_with_disk_stores.html],
> I should be able to start either of the servers without any problems as both
> host the most up to date data. However, what happens in reality is that the
> startup hangs with the following:
> {noformat}
> (1) Executing - start server --name=server1 --locators=localhost[10334]
> --server-port=40401 --cache-xml-file=/temporal/cache.xml
> .
> Region /TestRegion has potentially stale data. It is waiting for another
> member to recover the latest data.
> My persistent id:
> DiskStore ID: 4d1abaf3-677d-4c52-b3f8-681e051f143c
> Name: server1
> Location: /temporal/server1/dataStore
> Members with potentially new data:
> [
> DiskStore ID: 163dfaf7-a680-4154-a278-8cec40d57d80
> Name: server2
> Location: /temporal/server2/dataStore
> ]
> "main" #1 prio=5 os_prio=31 tid=0x7f9b28809000 nid=0x1003 in
> Object.wait() [0x7ab04000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at
> org.apache.geode.internal.cache.persistence.MembershipChangeListener.waitForChange(MembershipChangeListener.java:62)
> - locked <0x000719df55e0> (a
> org.apache.geode.internal.cache.persistence.MembershipChangeListener)
> at
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.waitForMembershipChangeForMissingDiskStores(PersistenceInitialImageAdvisor.java:218)
> at
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.getAdvice(PersistenceInitialImageAdvisor.java:118)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.getInitialImageAdvice(PersistenceAdvisorImpl.java:835)
> at
> org.apache.geode.internal.cache.persistence.CreatePersistentRegionProcessor.getInitialImageAdvice(CreatePersistentRegionProcessor.java:52)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1196)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1076)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3043)
> at
> org.apache.geode.pdx.internal.PeerTypeRegistration.initialize(PeerTypeRegistration.java:198)
> at
> org.apache.geode.pdx.internal.TypeRegistry.initialize(TypeRegistry.java:116)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializePdxRegistry(GemFireCacheImpl.java:1449)
> - locked <0x0005c0593168> (a
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:511)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4272)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1388)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1208)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:207)
> - locked <0x0005c016a108> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0x0005c0043de0> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:164)
> - locked <0x0005c0043de0> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:139)
> at
> org.apache.geode.d
[jira] [Updated] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-8800: - Labels: GeodeOperationAPI blocks-1.14.0 pull-request-available (was: GeodeOperationAPI pull-request-available) > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, blocks-1.14.0, pull-request-available > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259846#comment-17259846
]
ASF GitHub Bot commented on GEODE-8442:
---
pdxcodemonkey commented on pull request #713:
URL: https://github.com/apache/geode-native/pull/713#issuecomment-755397706
@mkevo Never mind the Windows build - these errors are coming from the
pipeline for the GEODE-85543 fix. I'll add the comment there.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolE
[jira] [Reopened] (GEODE-5922) SerialGatewaySenderQueue concurrency is poorly implemented
[ https://issues.apache.org/jira/browse/GEODE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt reopened GEODE-5922: --- The fix for this issue caused a 3x performance degradation in adding new events to the async queue. The fix needs to be reverted and reevaluated. A performance test of the AEQ with heavy load should be created to vet any new fix. > SerialGatewaySenderQueue concurrency is poorly implemented > -- > > Key: GEODE-5922 > URL: https://issues.apache.org/jira/browse/GEODE-5922 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This class uses synchronization on the queue to limit access to one put at a > time. Synchronization isn't a fair locking mechanism so threads can be > blocked trying to add events to the queue while other more recent events get > the lock and insert their events. This causes inconsistent latency which > I've observed being as long as 30 seconds, causing client connections to be > shut down by the ClientHealthMonitor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8786) INFO command hit/miss ratios should match native Redis
[
https://issues.apache.org/jira/browse/GEODE-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259864#comment-17259864
]
ASF GitHub Bot commented on GEODE-8786:
---
jhutchison commented on a change in pull request #5875:
URL: https://github.com/apache/geode/pull/5875#discussion_r552789616
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractHitsMissesIntegrationTest.java
##
@@ -82,6 +81,19 @@ public void testPttl() {
runCommandAndAssertHitsAndMisses("string", k -> jedis.pttl(k));
}
+ @Test
+ public void testRename() {
+Map info = getInfo(jedis);
+Long currentHits = Long.parseLong(info.get(HITS));
+Long currentMisses = Long.parseLong(info.get(MISSES));
+
+jedis.rename("string", "newString");
+
+info = getInfo(jedis);
+assertThat(info.get(HITS)).isEqualTo(String.valueOf(currentHits));
+assertThat(info.get(MISSES)).isEqualTo(String.valueOf(currentMisses));
Review comment:
thanks, changed
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> INFO command hit/miss ratios should match native Redis
> --
>
> Key: GEODE-8786
> URL: https://issues.apache.org/jira/browse/GEODE-8786
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Priority: Major
> Labels: pull-request-available
>
> Current hit/miss ratios for Geode Redis stats do not match those for native
> Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8696) Startup of JMX Manager may hang during crash of other members
[
https://issues.apache.org/jira/browse/GEODE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259866#comment-17259866
]
ASF GitHub Bot commented on GEODE-8696:
---
kirklund commented on pull request #5728:
URL: https://github.com/apache/geode/pull/5728#issuecomment-755415589
Random flaky test failed: GEODE-8528
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> Startup of JMX Manager may hang during crash of other members
> -
>
> Key: GEODE-8696
> URL: https://issues.apache.org/jira/browse/GEODE-8696
> Project: Geode
> Issue Type: Bug
> Components: jmx, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> The fix for GEODE-7400 removed final from the executorService field to
> introduce a Supplier. I think this hang was caused by adding
> synchronized to FederatingManager.executeTask instead of making
> executorService a volatile field.
> _vm_3_thr_3_client2_host2_21145_ hung while synchronized on
> *0xf6316520*:
> {noformat}
> "vm_3_thr_3_client2_host2_21145" #56 daemon prio=5 os_prio=0
> tid=0x7f1854002000 nid=0x5326 waiting on condition [0x7f18520e2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf6364030> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:244)
> at
> org.apache.geode.management.internal.FederatingManager.startManagingActivity(FederatingManager.java:256)
> at
> org.apache.geode.management.internal.FederatingManager.startManager(FederatingManager.java:121)
> - locked <0xf6316520> (a
> org.apache.geode.management.internal.FederatingManager)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:373)
> - locked <0xfed91a70> (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:197)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2089)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:643)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1363)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> - locked <0xe11065f0> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> hydra.CacheVersionHelper.configureAndCreateCache(CacheVersionHelper.java:51)
> at hydra.CacheHelper.createCacheWithHttpService(CacheHelper.java:127)
> - locked <0xfecab060> (a java.lang.Class for
> hydra.CacheHelper)
> at hydra.CacheHelper.createCache(CacheHelper.java:87)
> at
> splitBrain.NetworkPartitionTest.initialize(NetworkPartitionTest.java:293)
> at
> splitBrain.NetworkPartitionTest.initializeInstance(NetworkPartitionTest.java:228)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at
> splitBrain.NetworkPartitionTest.HydraTask_initialize(NetworkPartitionTest.java:203)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:6
[jira] [Updated] (GEODE-5922) SerialGatewaySenderQueue concurrency is poorly implemented
[ https://issues.apache.org/jira/browse/GEODE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt updated GEODE-5922: -- Labels: blocks-1.14.0 pull-request-available (was: pull-request-available) > SerialGatewaySenderQueue concurrency is poorly implemented > -- > > Key: GEODE-5922 > URL: https://issues.apache.org/jira/browse/GEODE-5922 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This class uses synchronization on the queue to limit access to one put at a > time. Synchronization isn't a fair locking mechanism so threads can be > blocked trying to add events to the queue while other more recent events get > the lock and insert their events. This causes inconsistent latency which > I've observed being as long as 30 seconds, causing client connections to be > shut down by the ClientHealthMonitor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8786) INFO command hit/miss ratios should match native Redis
[
https://issues.apache.org/jira/browse/GEODE-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259879#comment-17259879
]
ASF GitHub Bot commented on GEODE-8786:
---
jhutchison commented on a change in pull request #5875:
URL: https://github.com/apache/geode/pull/5875#discussion_r552806036
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractHitsMissesIntegrationTest.java
##
@@ -286,90 +306,312 @@ public void testHscan() {
runCommandAndAssertHitsAndMisses("hash", (k, v) -> jedis.hscan(k, v));
}
+ @Test
+ public void testHMSet() {
+Map info = getInfo(jedis);
+Long currentHits = Long.parseLong(info.get(HITS));
+Long currentMisses = Long.parseLong(info.get(MISSES));
+
+Map map = new HashMap<>();
+map.put("key1", "value1");
+map.put("key2", "value2");
+
+jedis.hmset("key", map);
Review comment:
done- had to create one with a new signature- not sure if this is the
best signature...
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> INFO command hit/miss ratios should match native Redis
> --
>
> Key: GEODE-8786
> URL: https://issues.apache.org/jira/browse/GEODE-8786
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Priority: Major
> Labels: pull-request-available
>
> Current hit/miss ratios for Geode Redis stats do not match those for native
> Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-8800: - Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI blocks-1.14.0 pull-request-available) > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8543) Client disconnects from server due to exception on other server
[ https://issues.apache.org/jira/browse/GEODE-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259921#comment-17259921 ] ASF GitHub Bot commented on GEODE-8543: --- pdxcodemonkey commented on pull request #705: URL: https://github.com/apache/geode-native/pull/705#issuecomment-755445765 @jvarenina I'm getting build errors on Windows: ``` C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(54): error C2079: 'previousTestLog' uses undefined class 'std::basic_ifstream>' [C:\build\cppcache\integration\test\cpp-integration-test.vcxproj] Building Custom Rule C:/nativeclient/cppcache/integration-test/CMakeLists.txt C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(54): error C2440: 'initializing': cannot convert from 'std::string' to 'int' [C:\build\cppcache\integration\test\cpp-integration-test.vcxproj] C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(54): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(168): error C2079: 'testLog' uses undefined class 'std::basic_ifstream>' [C:\build\cppcache\integration\test\cpp-integration-test.vcxproj] C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(168): error C2440: 'initializing': cannot convert from 'std::string' to 'int' [C:\build\cppcache\integration\test\cpp-integration-test.vcxproj] C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(168): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(174): error C2672: 'getline': no matching overloaded function found [C:\build\cppcache\integration\test\cpp-integration-test.vcxproj] testOverflowPutGetSqLite.cpp C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(174): error C2784: 'std::basic_istream<_Elem,_Traits> &std::getline(std::basic_istream<_Elem,_Traits> &,std::basic_string<_Elem,_Traits,_Alloc> &)': could not deduce template argument for 'std::basic_istream<_Elem,_Traits> &' from 'int' [C:\build\cppcache\integration\test\cpp-integration-test.vcxproj] Building Custom Rule C:/nativeclient/cppcache/integration-test/CMakeLists.txt testThinClientInterest1Cacheless.cpp C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\string(160): note: see declaration of 'std::getline' C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(174): error C2780: 'std::basic_istream<_Elem,_Traits> &std::getline(std::basic_istream<_Elem,_Traits> &,std::basic_string<_Elem,_Traits,_Alloc> &,const _Elem)': expects 3 arguments - 2 provided [C:\build\cppcache\integration\test\cpp-integration-test.vcxproj] C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\string(149): note: see declaration of 'std::getline' testThinClientRegex3.cpp C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(174): error C2784: 'std::basic_istream<_Elem,_Traits> &std::getline(std::basic_istream<_Elem,_Traits> &&,std::basic_string<_Elem,_Traits,_Alloc> &)': could not deduce template argument for 'std::basic_istream<_Elem,_Traits> &&' from 'int' [C:\build\cppcache\integration\test\cpp-integration-test.vcxproj] C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\string(129): note: see declaration of 'std::getline' C:\nativeclient\cppcache\integration\test\DisconnectEndPointAtException.cpp(174): error C2780: 'std::basic_istream<_Elem,_Traits> &std::getline(std::basic_istream<_Elem,_Traits> &&,std::basic_string<_Elem,_Traits,_Alloc> &,const _Elem)': expects 3 arguments - 2 provided [C:\build\cppcache\integration\test\cpp-integration-test.vcxproj] C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\string(76): note: see declaration of 'std::getline' testThinClientLargePutAllWithCallBackArg.cpp ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 > Client disconnects from server due to exception on other server > --- > > Key: GEODE-8543 > URL: https://issues.apache.org/jira/browse/GEODE-8543 > Project: Geode > Is
[jira] [Commented] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259924#comment-17259924
]
ASF subversion and git services commented on GEODE-8789:
Commit ec21170c5a1104b40e980ea0597716f862c8d464 in geode's branch
refs/heads/support/1.13 from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec21170 ]
GEODE-8789: Prevent region name from being incorrectly logged twice
- Do not format the String containing the reason for the exception to
contain the region name
Authored-by: Donal Evans
(cherry picked from commit c723c046a82e33a50c5a138753b0466515b3230c)
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Affects Versions: 1.12.0, 1.14.0, 1.13.1
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8789:
---
Fix Version/s: 1.13.2
1.12.1
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Affects Versions: 1.12.0, 1.14.0, 1.13.1
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.2
>
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259925#comment-17259925
]
ASF subversion and git services commented on GEODE-8789:
Commit edd54168d90562556451d769ccd1fd75bbdb8a45 in geode's branch
refs/heads/support/1.12 from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=edd5416 ]
GEODE-8789: Prevent region name from being incorrectly logged twice
- Do not format the String containing the reason for the exception to
contain the region name
Authored-by: Donal Evans
(cherry picked from commit c723c046a82e33a50c5a138753b0466515b3230c)
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Affects Versions: 1.12.0, 1.14.0, 1.13.1
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.2
>
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8808) Missing CQ events for puts
Nabarun Nag created GEODE-8808: -- Summary: Missing CQ events for puts Key: GEODE-8808 URL: https://issues.apache.org/jira/browse/GEODE-8808 Project: Geode Issue Type: Bug Components: cq Reporter: Nabarun Nag After a certain number of puts, CQ are missing afterCreate. There is a mismatch between number of CQ events and puts -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8808) Missing CQ events for puts
[ https://issues.apache.org/jira/browse/GEODE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag updated GEODE-8808: --- Labels: blocks-1.14.0 (was: ) > Missing CQ events for puts > -- > > Key: GEODE-8808 > URL: https://issues.apache.org/jira/browse/GEODE-8808 > Project: Geode > Issue Type: Bug > Components: cq >Reporter: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0 > > After a certain number of puts, CQ are missing afterCreate. There is a > mismatch between number of CQ events and puts -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8786) INFO command hit/miss ratios should match native Redis
[
https://issues.apache.org/jira/browse/GEODE-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259935#comment-17259935
]
ASF GitHub Bot commented on GEODE-8786:
---
nonbinaryprogrammer commented on a change in pull request #5875:
URL: https://github.com/apache/geode/pull/5875#discussion_r552860024
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/data/RedisSetCommandsFunctionExecutor.java
##
@@ -37,18 +37,22 @@ public RedisSetCommandsFunctionExecutor(
super(helper);
}
- private RedisSet getRedisSet(ByteArrayWrapper key) {
-return helper.getRedisSet(key);
+ private RedisSet getRedisSet(ByteArrayWrapper key, boolean updateStats) {
Review comment:
I think I made the change that you suggested but I'm not positive that I
understood this correctly
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> INFO command hit/miss ratios should match native Redis
> --
>
> Key: GEODE-8786
> URL: https://issues.apache.org/jira/browse/GEODE-8786
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Priority: Major
> Labels: pull-request-available
>
> Current hit/miss ratios for Geode Redis stats do not match those for native
> Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5922) SerialGatewaySenderQueue concurrency is poorly implemented
[ https://issues.apache.org/jira/browse/GEODE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259940#comment-17259940 ] ASF GitHub Bot commented on GEODE-5922: --- bschuchardt merged pull request #5870: URL: https://github.com/apache/geode/pull/5870 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 > SerialGatewaySenderQueue concurrency is poorly implemented > -- > > Key: GEODE-5922 > URL: https://issues.apache.org/jira/browse/GEODE-5922 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This class uses synchronization on the queue to limit access to one put at a > time. Synchronization isn't a fair locking mechanism so threads can be > blocked trying to add events to the queue while other more recent events get > the lock and insert their events. This causes inconsistent latency which > I've observed being as long as 30 seconds, causing client connections to be > shut down by the ClientHealthMonitor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-5922) SerialGatewaySenderQueue concurrency is poorly implemented
[ https://issues.apache.org/jira/browse/GEODE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259941#comment-17259941 ] ASF subversion and git services commented on GEODE-5922: Commit ab16f68c7c3b121af00c3aca64a92d9809cb6019 in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ab16f68 ] GEODE-5922: concurrency problems in SerialGatewaySenderQueue (#5870) reverting 3ed37a754d789bb52cf190db23088e819955fd58 for performance testing > SerialGatewaySenderQueue concurrency is poorly implemented > -- > > Key: GEODE-5922 > URL: https://issues.apache.org/jira/browse/GEODE-5922 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This class uses synchronization on the queue to limit access to one put at a > time. Synchronization isn't a fair locking mechanism so threads can be > blocked trying to add events to the queue while other more recent events get > the lock and insert their events. This causes inconsistent latency which > I've observed being as long as 30 seconds, causing client connections to be > shut down by the ClientHealthMonitor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8809) Servers are missing heartbeats from a member
Nabarun Nag created GEODE-8809: -- Summary: Servers are missing heartbeats from a member Key: GEODE-8809 URL: https://issues.apache.org/jira/browse/GEODE-8809 Project: Geode Issue Type: Bug Components: messaging Reporter: Nabarun Nag * The coordinator is requesting availability test from a member, * member gets it after a delay * the delay causes the server to be kicked out. * operations fail. * server reconnects. We need figure out why the delay occurs, handle the disconnect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8809) Servers are missing heartbeats from a member
[ https://issues.apache.org/jira/browse/GEODE-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag updated GEODE-8809: --- Labels: blocks-1.14.0 (was: ) > Servers are missing heartbeats from a member > > > Key: GEODE-8809 > URL: https://issues.apache.org/jira/browse/GEODE-8809 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0 > > * The coordinator is requesting availability test from a member, > * member gets it after a delay > * the delay causes the server to be kicked out. > * operations fail. > * server reconnects. > > We need figure out why the delay occurs, handle the disconnect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8810) Event not delivered to remote site in WAN
Nabarun Nag created GEODE-8810: -- Summary: Event not delivered to remote site in WAN Key: GEODE-8810 URL: https://issues.apache.org/jira/browse/GEODE-8810 Project: Geode Issue Type: Bug Components: wan Reporter: Nabarun Nag If the secondary parallel wan queue received the ParallelQueueRemovalMessage before the primary wan queue successfully deliver the event to remote site, and node with primary wan queue will be killed/lost. The remote site was not able to receive the event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8810) Event not delivered to remote site in WAN
[ https://issues.apache.org/jira/browse/GEODE-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag updated GEODE-8810: --- Labels: blocks-1.14.0 (was: ) > Event not delivered to remote site in WAN > - > > Key: GEODE-8810 > URL: https://issues.apache.org/jira/browse/GEODE-8810 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0 > > If the secondary parallel wan queue received the ParallelQueueRemovalMessage > before the primary wan queue successfully deliver the event to remote site, > and node with primary wan queue will be killed/lost. > The remote site was not able to receive the event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8811) Create events are fired as update events
Nabarun Nag created GEODE-8811: -- Summary: Create events are fired as update events Key: GEODE-8811 URL: https://issues.apache.org/jira/browse/GEODE-8811 Project: Geode Issue Type: Bug Components: cq Reporter: Nabarun Nag When the failing client fires the event for an object during register interest ... it shows the expected value as the "oldValue" (vs. the newValue) ... and newValue == null and the OperationType as UPDATE (vs. CREATE). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8811) Create events are fired as update events
[ https://issues.apache.org/jira/browse/GEODE-8811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag updated GEODE-8811: --- Labels: blocks-1.14.0 (was: ) > Create events are fired as update events > > > Key: GEODE-8811 > URL: https://issues.apache.org/jira/browse/GEODE-8811 > Project: Geode > Issue Type: Bug > Components: cq >Reporter: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0 > > When the failing client fires the event for an object during register > interest ... it shows the expected value as the "oldValue" (vs. the newValue) > ... and newValue == null and the OperationType as UPDATE (vs. CREATE). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8812) Puts per second are slower
[ https://issues.apache.org/jira/browse/GEODE-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag updated GEODE-8812: --- Labels: blocks-1.14.0 (was: ) > Puts per second are slower > -- > > Key: GEODE-8812 > URL: https://issues.apache.org/jira/browse/GEODE-8812 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0 > > In a comparison of 9.10.0 (build 1020) vs. 1.14 (build 18), we see at least a > 5% > degradation in putsPerSecond in all 3 runs on the comparison build (1.14-b18). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8812) Puts per second are slower
Nabarun Nag created GEODE-8812: -- Summary: Puts per second are slower Key: GEODE-8812 URL: https://issues.apache.org/jira/browse/GEODE-8812 Project: Geode Issue Type: Bug Components: benchmarks Reporter: Nabarun Nag In a comparison of 9.10.0 (build 1020) vs. 1.14 (build 18), we see at least a 5% degradation in putsPerSecond in all 3 runs on the comparison build (1.14-b18). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8671) Two threads calling get and retrieve the same PdxInstance, resulting in corruption
[ https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag updated GEODE-8671: --- Labels: blocks-1.14.0 caching-applications (was: caching-applications) > Two threads calling get and retrieve the same PdxInstance, resulting in > corruption > -- > > Key: GEODE-8671 > URL: https://issues.apache.org/jira/browse/GEODE-8671 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Dan Smith >Priority: Major > Labels: blocks-1.14.0, caching-applications > > Even if copy-on-read is set to true, two threads calling get on a partitioned > region can end up with the same PdxInstance object. > This is problematic because some PdxInstances methods are not thread safe. > Although the underlying bytes are immutatable, the PDXInstance has a > ByteSource with a position field that changes. That means two threads doing > serialization or calling toString on the PdxInstance could result in one or > more threads getting a corrupt read. > It looks like they are ending up with the same instance because of the > behavior in LocalRegion.optimizedGetObject. We use futures to make sure there > is only 1 get that goes through, and both threads receive the same value. > > Ending up in optimizedGetObject requires a race with the put, because if the > value was in the cache at the beginning of the get it would be returned > earlier in the get process. > I put a test that reproduces this issue here - > https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8813) CreateRegionCommandDUnitTest flaky
Raymond Ingles created GEODE-8813:
-
Summary: CreateRegionCommandDUnitTest flaky
Key: GEODE-8813
URL: https://issues.apache.org/jira/browse/GEODE-8813
Project: Geode
Issue Type: Bug
Components: gfsh
Affects Versions: 1.14.0
Reporter: Raymond Ingles
Two failures in build #684:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/684|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/684]
{{> Task :geode-gfsh:distributedTest
org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest
> ensureOverridingCallbacksFromTemplateDoNotRequireClassesOnLocator FAILED
org.junit.ComparisonFailure: [Region /TEMPLATE already exists on the
cluster.
] expected:<[OK]> but was:<[ERROR]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
at
org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest.ensureOverridingCallbacksFromTemplateDoNotRequireClassesOnLocator(CreateRegionCommandDUnitTest.java:406)
org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest
> ensureNewCallbacksFromTemplateDoNotRequireClassesOnLocator FAILED
org.junit.ComparisonFailure: [Region /TEMPLATE already exists on the
cluster.
] expected:<[OK]> but was:<[ERROR]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
at
org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest.ensureNewCallbacksFromTemplateDoNotRequireClassesOnLocator(CreateRegionCommandDUnitTest.java:449)}}
Passed in the next build, so possibly a transient issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8813) CreateRegionCommandDUnitTest flaky
[
https://issues.apache.org/jira/browse/GEODE-8813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259968#comment-17259968
]
Geode Integration commented on GEODE-8813:
--
Seen in [DistributedTestOpenJDK11
#684|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/684]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0580/test-results/distributedTest/1609896511/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0580/test-artifacts/1609896511/distributedtestfiles-OpenJDK11-1.14.0-build.0580.tgz].
> CreateRegionCommandDUnitTest flaky
> --
>
> Key: GEODE-8813
> URL: https://issues.apache.org/jira/browse/GEODE-8813
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Assignee: Jinmei Liao
>Priority: Major
>
> Two failures in build #684:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/684|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/684]
> {{> Task :geode-gfsh:distributedTest
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest
> > ensureOverridingCallbacksFromTemplateDoNotRequireClassesOnLocator FAILED
> org.junit.ComparisonFailure: [Region /TEMPLATE already exists on the
> cluster.
> ] expected:<[OK]> but was:<[ERROR]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
> at
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest.ensureOverridingCallbacksFromTemplateDoNotRequireClassesOnLocator(CreateRegionCommandDUnitTest.java:406)
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest
> > ensureNewCallbacksFromTemplateDoNotRequireClassesOnLocator FAILED
> org.junit.ComparisonFailure: [Region /TEMPLATE already exists on the
> cluster.
> ] expected:<[OK]> but was:<[ERROR]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
> at
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest.ensureNewCallbacksFromTemplateDoNotRequireClassesOnLocator(CreateRegionCommandDUnitTest.java:449)}}
> Passed in the next build, so possibly a transient issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8813) CreateRegionCommandDUnitTest flaky
[
https://issues.apache.org/jira/browse/GEODE-8813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Ingles reassigned GEODE-8813:
-
Assignee: Jinmei Liao
> CreateRegionCommandDUnitTest flaky
> --
>
> Key: GEODE-8813
> URL: https://issues.apache.org/jira/browse/GEODE-8813
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Assignee: Jinmei Liao
>Priority: Major
>
> Two failures in build #684:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/684|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/684]
> {{> Task :geode-gfsh:distributedTest
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest
> > ensureOverridingCallbacksFromTemplateDoNotRequireClassesOnLocator FAILED
> org.junit.ComparisonFailure: [Region /TEMPLATE already exists on the
> cluster.
> ] expected:<[OK]> but was:<[ERROR]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
> at
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest.ensureOverridingCallbacksFromTemplateDoNotRequireClassesOnLocator(CreateRegionCommandDUnitTest.java:406)
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest
> > ensureNewCallbacksFromTemplateDoNotRequireClassesOnLocator FAILED
> org.junit.ComparisonFailure: [Region /TEMPLATE already exists on the
> cluster.
> ] expected:<[OK]> but was:<[ERROR]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
> at
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandDUnitTest.ensureNewCallbacksFromTemplateDoNotRequireClassesOnLocator(CreateRegionCommandDUnitTest.java:449)}}
> Passed in the next build, so possibly a transient issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259969#comment-17259969 ] ASF GitHub Bot commented on GEODE-8800: --- dschneider-pivotal commented on a change in pull request #5879: URL: https://github.com/apache/geode/pull/5879#discussion_r552891572 ## File path: geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfigImpl.java ## @@ -1030,6 +1032,20 @@ public DistributionConfigImpl(Properties nonDefault, boolean ignoreGemFirePropsF modifiable = false; } + /* + * When ssl-enabled-components specified CLUSTER or ALL, the slower receiver is not allowed. Review comment: I noticed here and in your test method names you use "slower". Change that to "slow". It is a "slow receiver" not a "slower receiver". This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8800) SSL is supposed to disable slower receiver feature
[
https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259973#comment-17259973
]
ASF GitHub Bot commented on GEODE-8800:
---
kirklund commented on a change in pull request #5879:
URL: https://github.com/apache/geode/pull/5879#discussion_r552895539
##
File path:
geode-core/src/integrationTest/java/org/apache/geode/internal/SSLConfigJUnitTest.java
##
@@ -153,6 +156,66 @@ public static void initializeSSLMaps() {
@After
public void tearDownTest() {}
+ @Test
+ public void slowerReceiverShouldThrowExceptionWhenEnabledClusterTLS() throws
Exception {
+Properties props = new Properties();
+props.setProperty(SSL_ENABLED_COMPONENTS, "cluster");
+props.setProperty(ASYNC_DISTRIBUTION_TIMEOUT, "1");
+
+try {
Review comment:
I recommend using AssertJ catchThrowable for these expected exceptions.
It would end up looking like:
```
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.catchThrowable;
Throwable thrown = catchThrowable(() -> new DistributionConfigImpl(props));
assertThat(thrown)
.isInstanceOf(IllegalArgumentException.class)
.hasMessageContaining("async-distribution-timeout greater than 0 is not
allowed with cluster TLS/SSL.");
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> SSL is supposed to disable slower receiver feature
> --
>
> Key: GEODE-8800
> URL: https://issues.apache.org/jira/browse/GEODE-8800
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> According to document, slow receiver options are disabled in systems using
> SSL
> (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html).
>
> But TLS tests found it did not. If the cluster specified
> async-distribution-timeout to 1 aggressively, it will cause SSL test to hang.
> When distribution took longer than async-distribution-timeout, even d-ack
> region will be using async message queue, which conflicts with SSL.
>
> There're 2 alternatives to fix:
> (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw
> exception.
> (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it
> configed >0.
> We decide to take alternative-(1).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8696) Startup of JMX Manager may hang during crash of other members
[
https://issues.apache.org/jira/browse/GEODE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259977#comment-17259977
]
ASF GitHub Bot commented on GEODE-8696:
---
kirklund closed pull request #5834:
URL: https://github.com/apache/geode/pull/5834
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> Startup of JMX Manager may hang during crash of other members
> -
>
> Key: GEODE-8696
> URL: https://issues.apache.org/jira/browse/GEODE-8696
> Project: Geode
> Issue Type: Bug
> Components: jmx, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> The fix for GEODE-7400 removed final from the executorService field to
> introduce a Supplier. I think this hang was caused by adding
> synchronized to FederatingManager.executeTask instead of making
> executorService a volatile field.
> _vm_3_thr_3_client2_host2_21145_ hung while synchronized on
> *0xf6316520*:
> {noformat}
> "vm_3_thr_3_client2_host2_21145" #56 daemon prio=5 os_prio=0
> tid=0x7f1854002000 nid=0x5326 waiting on condition [0x7f18520e2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf6364030> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:244)
> at
> org.apache.geode.management.internal.FederatingManager.startManagingActivity(FederatingManager.java:256)
> at
> org.apache.geode.management.internal.FederatingManager.startManager(FederatingManager.java:121)
> - locked <0xf6316520> (a
> org.apache.geode.management.internal.FederatingManager)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:373)
> - locked <0xfed91a70> (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:197)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2089)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:643)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1363)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> - locked <0xe11065f0> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> - locked <0xe1101220> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> hydra.CacheVersionHelper.configureAndCreateCache(CacheVersionHelper.java:51)
> at hydra.CacheHelper.createCacheWithHttpService(CacheHelper.java:127)
> - locked <0xfecab060> (a java.lang.Class for
> hydra.CacheHelper)
> at hydra.CacheHelper.createCache(CacheHelper.java:87)
> at
> splitBrain.NetworkPartitionTest.initialize(NetworkPartitionTest.java:293)
> at
> splitBrain.NetworkPartitionTest.initializeInstance(NetworkPartitionTest.java:228)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at
> splitBrain.NetworkPartitionTest.HydraTask_initialize(NetworkPartitionTest.java:203)
> - locked <0xe14a2db0> (a java.lang.Class for
> splitBrain.NetworkPartitionTest)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invok
[jira] [Commented] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259980#comment-17259980 ] ASF GitHub Bot commented on GEODE-8800: --- jinmeiliao commented on pull request #5879: URL: https://github.com/apache/geode/pull/5879#issuecomment-755507388 As far as I know, we rarely do multi-property cross validation at startup, i.e, we don't check if property A is set then property B can't be set. Initial validation is usually based on one property only (i.e integer is between a number and string is only a certain values etc.). Multi-property conflict is usually handled by ignoring one property (if A is set, then B has no effect). I wonder if we should take this route instead. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259991#comment-17259991 ] ASF GitHub Bot commented on GEODE-8800: --- gesterzhou commented on a change in pull request #5879: URL: https://github.com/apache/geode/pull/5879#discussion_r552904727 ## File path: geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfigImpl.java ## @@ -1030,6 +1032,20 @@ public DistributionConfigImpl(Properties nonDefault, boolean ignoreGemFirePropsF modifiable = false; } + /* + * When ssl-enabled-components specified CLUSTER or ALL, the slower receiver is not allowed. Review comment: fixed. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259993#comment-17259993 ] ASF GitHub Bot commented on GEODE-8800: --- gesterzhou commented on pull request #5879: URL: https://github.com/apache/geode/pull/5879#issuecomment-755525002 We discussed the alternative to ignore the async-distribution-timeout when SSL is enabled. Finally we decided to throw exception instead of silently ignore it. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-5922) SerialGatewaySenderQueue concurrency is poorly implemented
[ https://issues.apache.org/jira/browse/GEODE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17259995#comment-17259995 ] ASF subversion and git services commented on GEODE-5922: Commit 2dfef383298035d6a65b939c5d0edef5060bcd46 in geode's branch refs/heads/support/1.13 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2dfef38 ] GEODE-5922: concurrency problems in SerialGatewaySenderQueue (#5870) reverting 3ed37a754d789bb52cf190db23088e819955fd58 (cherry picked from commit ab16f68c7c3b121af00c3aca64a92d9809cb6019) > SerialGatewaySenderQueue concurrency is poorly implemented > -- > > Key: GEODE-5922 > URL: https://issues.apache.org/jira/browse/GEODE-5922 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This class uses synchronization on the queue to limit access to one put at a > time. Synchronization isn't a fair locking mechanism so threads can be > blocked trying to add events to the queue while other more recent events get > the lock and insert their events. This causes inconsistent latency which > I've observed being as long as 30 seconds, causing client connections to be > shut down by the ClientHealthMonitor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8782) Add getPrincipal method to FunctionContext interface
[
https://issues.apache.org/jira/browse/GEODE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1726#comment-1726
]
ASF GitHub Bot commented on GEODE-8782:
---
jdeppe-pivotal opened a new pull request #5880:
URL: https://github.com/apache/geode/pull/5880
- Add the ability to retrieve the Principal from the FunctionContext
when a SecurityManager is enabled.
(cherry picked from commit a42f89ab48aaca9aac96a34e80a9b3b2d46bcddd)
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, check Concourse 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 to 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
> Add getPrincipal method to FunctionContext interface
>
>
> Key: GEODE-8782
> URL: https://issues.apache.org/jira/browse/GEODE-8782
> Project: Geode
> Issue Type: New Feature
> Components: core
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> In some cases it would be very helpful to have access to the {{Principal}}
> when executing a function.
> It may seem obvious that if one has a reference to the {{cache}} that you
> could get to the {{SecurityManager}} and extract the {{Subject}} and thus the
> {{Principal}} from there. However, in some cases, Geode will seamlessly proxy
> a function call from one server to the other. This will typically happen with
> {{onRegion}} calls and partitioned regions. In such cases, the security
> context is lost and thus the principal is not accessible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8814) StressNewTestHelper is not specifying multiple tests correctly
Jens Deppe created GEODE-8814:
-
Summary: StressNewTestHelper is not specifying multiple tests
correctly
Key: GEODE-8814
URL: https://issues.apache.org/jira/browse/GEODE-8814
Project: Geode
Issue Type: Bug
Components: build
Reporter: Jens Deppe
When multiple tests are run the gradle command should be something like:
{code:java}
integrationTest --tests A --tests B
{code}
However, the current output is comma separated which is wrong:
{code:java}
integrationTest --tests A,B
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8800) SSL is supposed to disable slower receiver feature
[
https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260009#comment-17260009
]
ASF GitHub Bot commented on GEODE-8800:
---
gesterzhou commented on a change in pull request #5879:
URL: https://github.com/apache/geode/pull/5879#discussion_r552915040
##
File path:
geode-core/src/integrationTest/java/org/apache/geode/internal/SSLConfigJUnitTest.java
##
@@ -153,6 +156,66 @@ public static void initializeSSLMaps() {
@After
public void tearDownTest() {}
+ @Test
+ public void slowerReceiverShouldThrowExceptionWhenEnabledClusterTLS() throws
Exception {
+Properties props = new Properties();
+props.setProperty(SSL_ENABLED_COMPONENTS, "cluster");
+props.setProperty(ASYNC_DISTRIBUTION_TIMEOUT, "1");
+
+try {
Review comment:
Fixed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> SSL is supposed to disable slower receiver feature
> --
>
> Key: GEODE-8800
> URL: https://issues.apache.org/jira/browse/GEODE-8800
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> According to document, slow receiver options are disabled in systems using
> SSL
> (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html).
>
> But TLS tests found it did not. If the cluster specified
> async-distribution-timeout to 1 aggressively, it will cause SSL test to hang.
> When distribution took longer than async-distribution-timeout, even d-ack
> region will be using async message queue, which conflicts with SSL.
>
> There're 2 alternatives to fix:
> (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw
> exception.
> (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it
> configed >0.
> We decide to take alternative-(1).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8814) StressNewTestHelper is not specifying multiple tests correctly
[
https://issues.apache.org/jira/browse/GEODE-8814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8814:
--
Labels: pull-request-available (was: )
> StressNewTestHelper is not specifying multiple tests correctly
> --
>
> Key: GEODE-8814
> URL: https://issues.apache.org/jira/browse/GEODE-8814
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> When multiple tests are run the gradle command should be something like:
> {code:java}
> integrationTest --tests A --tests B
> {code}
> However, the current output is comma separated which is wrong:
> {code:java}
> integrationTest --tests A,B
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8814) StressNewTestHelper is not specifying multiple tests correctly
[
https://issues.apache.org/jira/browse/GEODE-8814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260011#comment-17260011
]
ASF GitHub Bot commented on GEODE-8814:
---
jdeppe-pivotal opened a new pull request #5881:
URL: https://github.com/apache/geode/pull/5881
- Multiple tests should each declare a separate `--tests` option instead
of being comma separated.
Authored-by: Jens Deppe
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, check Concourse 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 to 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
> StressNewTestHelper is not specifying multiple tests correctly
> --
>
> Key: GEODE-8814
> URL: https://issues.apache.org/jira/browse/GEODE-8814
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Jens Deppe
>Priority: Major
>
> When multiple tests are run the gradle command should be something like:
> {code:java}
> integrationTest --tests A --tests B
> {code}
> However, the current output is comma separated which is wrong:
> {code:java}
> integrationTest --tests A,B
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5922) SerialGatewaySenderQueue concurrency is poorly implemented
[ https://issues.apache.org/jira/browse/GEODE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260024#comment-17260024 ] ASF subversion and git services commented on GEODE-5922: Commit ec2d79ebfd0b85fc90203c3c114c4b3eec37602f in geode's branch refs/heads/support/1.12 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec2d79e ] GEODE-5922: concurrency problems in SerialGatewaySenderQueue (#5870) reverting 3ed37a754d789bb52cf190db23088e819955fd58 (cherry picked from commit ab16f68c7c3b121af00c3aca64a92d9809cb6019) > SerialGatewaySenderQueue concurrency is poorly implemented > -- > > Key: GEODE-5922 > URL: https://issues.apache.org/jira/browse/GEODE-5922 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This class uses synchronization on the queue to limit access to one put at a > time. Synchronization isn't a fair locking mechanism so threads can be > blocked trying to add events to the queue while other more recent events get > the lock and insert their events. This causes inconsistent latency which > I've observed being as long as 30 seconds, causing client connections to be > shut down by the ClientHealthMonitor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8790) Evicted entries sometimes remain in region map
[
https://issues.apache.org/jira/browse/GEODE-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260066#comment-17260066
]
ASF GitHub Bot commented on GEODE-8790:
---
dschneider-pivotal commented on a change in pull request #5851:
URL: https://github.com/apache/geode/pull/5851#discussion_r552972357
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/map/RegionMapDestroy.java
##
@@ -372,6 +372,8 @@ private void retryRemoveWithTombstone() {
} finally {
removeEntryOrLeaveTombstone();
}
+} else if (regionEntry == null && !newRegionEntry.isTombstone()) {
Review comment:
I think it would be better to change it so the only the we don't do if
we are evicting is handleEntryNotFound(). When evicting we do not want an
exception if the entry is already gone.
So I would change line 369 to just be an "else" and then put a "if
(!isEviction)" on handleEntryNotFound (even better might be to change
handleEntryNotFound to test isEviction and return since this is the only place
it is called).
Then you can get rid of your new code on 375 and 376.
I do think it is probably correct to call removeEntryOrLeaveTombstone for an
eviction just to make sure it follows the normal rules of scheduling a
tombstone when concurrency checks are enabled. This method is already a noop if
evicting without concurrency checks.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
> Evicted entries sometimes remain in region map
> --
>
> Key: GEODE-8790
> URL: https://issues.apache.org/jira/browse/GEODE-8790
> Project: Geode
> Issue Type: Bug
> Components: eviction
>Affects Versions: 1.1.0, 1.14.0
>Reporter: Louis R. Jacome
>Assignee: Louis R. Jacome
>Priority: Major
> Labels: pull-request-available
>
> Sometimes an entry set for eviction will remain in the region map after
> falling into an unhandled case in RegionMapDestroy.retryRemoveWithTombstone.
> When testing the LRU capacity of a region, we create many entries beyond the
> LRU capacity, causing evictions. We sometimes run into a case where two
> threads compete to remove the same entry. One thread succeeds and removes it
> from the region map, while the other thread, in removal progress, will create
> a temporary entry in the map that does not get properly removed/handled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260076#comment-17260076 ] ASF GitHub Bot commented on GEODE-8800: --- dschneider-pivotal commented on pull request #5879: URL: https://github.com/apache/geode/pull/5879#issuecomment-755739949 My concern was that we can have a cluster in which all the members use SSL but we might only have some of them configure slow receiver. But if that happens then any of the members that configured slow receiver will fail to start (with this change) so I think this current PR is enough without adding an additional check in Connection.readHandshakeForSender This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5922) SerialGatewaySenderQueue concurrency is poorly implemented
[ https://issues.apache.org/jira/browse/GEODE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt resolved GEODE-5922. --- Resolution: Won't Fix The fix for this problem has been reverted on develop and all support branches. The change to use a fair lock instead of Java synchronization caused queuing to be about 3x slower under heavy load. > SerialGatewaySenderQueue concurrency is poorly implemented > -- > > Key: GEODE-5922 > URL: https://issues.apache.org/jira/browse/GEODE-5922 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This class uses synchronization on the queue to limit access to one put at a > time. Synchronization isn't a fair locking mechanism so threads can be > blocked trying to add events to the queue while other more recent events get > the lock and insert their events. This causes inconsistent latency which > I've observed being as long as 30 seconds, causing client connections to be > shut down by the ClientHealthMonitor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8802) Clarify mcast-port default in Docs
[ https://issues.apache.org/jira/browse/GEODE-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260101#comment-17260101 ] ASF GitHub Bot commented on GEODE-8802: --- karensmolermiller merged pull request #5872: URL: https://github.com/apache/geode/pull/5872 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 > Clarify mcast-port default in Docs > -- > > Key: GEODE-8802 > URL: https://issues.apache.org/jira/browse/GEODE-8802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > In > [https://geode.apache.org/docs/guide/113/configuring/running/firewalls_ports.html,] > in the subsection called Default Port Configurations, the default port value > for mcast-port is not quite correct. It says the default is 10334. It > should instead say that the default is 0 when the locators property is set, > and 10334 when the locators property is not set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8802) Clarify mcast-port default in Docs
[ https://issues.apache.org/jira/browse/GEODE-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260104#comment-17260104 ] ASF subversion and git services commented on GEODE-8802: Commit 019e03b6707de054dd15a5e75a85332ee8eb51f0 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=019e03b ] GEODE-8802: clarify mcast-port default in docs (#5872) * GEODE-8802: clarify mcast-port default in docs * GEODE-8802: Revise mcast-port default value to be 0 in docs * GEODE-8802: clarify mcast-port default in docs Co-authored-by: Karen Miller > Clarify mcast-port default in Docs > -- > > Key: GEODE-8802 > URL: https://issues.apache.org/jira/browse/GEODE-8802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > In > [https://geode.apache.org/docs/guide/113/configuring/running/firewalls_ports.html,] > in the subsection called Default Port Configurations, the default port value > for mcast-port is not quite correct. It says the default is 10334. It > should instead say that the default is 0 when the locators property is set, > and 10334 when the locators property is not set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8802) Clarify mcast-port default in Docs
[ https://issues.apache.org/jira/browse/GEODE-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260105#comment-17260105 ] ASF subversion and git services commented on GEODE-8802: Commit 019e03b6707de054dd15a5e75a85332ee8eb51f0 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=019e03b ] GEODE-8802: clarify mcast-port default in docs (#5872) * GEODE-8802: clarify mcast-port default in docs * GEODE-8802: Revise mcast-port default value to be 0 in docs * GEODE-8802: clarify mcast-port default in docs Co-authored-by: Karen Miller > Clarify mcast-port default in Docs > -- > > Key: GEODE-8802 > URL: https://issues.apache.org/jira/browse/GEODE-8802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > In > [https://geode.apache.org/docs/guide/113/configuring/running/firewalls_ports.html,] > in the subsection called Default Port Configurations, the default port value > for mcast-port is not quite correct. It says the default is 10334. It > should instead say that the default is 0 when the locators property is set, > and 10334 when the locators property is not set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8802) Clarify mcast-port default in Docs
[ https://issues.apache.org/jira/browse/GEODE-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260102#comment-17260102 ] ASF subversion and git services commented on GEODE-8802: Commit 019e03b6707de054dd15a5e75a85332ee8eb51f0 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=019e03b ] GEODE-8802: clarify mcast-port default in docs (#5872) * GEODE-8802: clarify mcast-port default in docs * GEODE-8802: Revise mcast-port default value to be 0 in docs * GEODE-8802: clarify mcast-port default in docs Co-authored-by: Karen Miller > Clarify mcast-port default in Docs > -- > > Key: GEODE-8802 > URL: https://issues.apache.org/jira/browse/GEODE-8802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > In > [https://geode.apache.org/docs/guide/113/configuring/running/firewalls_ports.html,] > in the subsection called Default Port Configurations, the default port value > for mcast-port is not quite correct. It says the default is 10334. It > should instead say that the default is 0 when the locators property is set, > and 10334 when the locators property is not set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8802) Clarify mcast-port default in Docs
[ https://issues.apache.org/jira/browse/GEODE-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260103#comment-17260103 ] ASF subversion and git services commented on GEODE-8802: Commit 019e03b6707de054dd15a5e75a85332ee8eb51f0 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=019e03b ] GEODE-8802: clarify mcast-port default in docs (#5872) * GEODE-8802: clarify mcast-port default in docs * GEODE-8802: Revise mcast-port default value to be 0 in docs * GEODE-8802: clarify mcast-port default in docs Co-authored-by: Karen Miller > Clarify mcast-port default in Docs > -- > > Key: GEODE-8802 > URL: https://issues.apache.org/jira/browse/GEODE-8802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > In > [https://geode.apache.org/docs/guide/113/configuring/running/firewalls_ports.html,] > in the subsection called Default Port Configurations, the default port value > for mcast-port is not quite correct. It says the default is 10334. It > should instead say that the default is 0 when the locators property is set, > and 10334 when the locators property is not set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8802) Clarify mcast-port default in Docs
[ https://issues.apache.org/jira/browse/GEODE-8802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-8802. Fix Version/s: 1.14.0 Resolution: Fixed > Clarify mcast-port default in Docs > -- > > Key: GEODE-8802 > URL: https://issues.apache.org/jira/browse/GEODE-8802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > In > [https://geode.apache.org/docs/guide/113/configuring/running/firewalls_ports.html,] > in the subsection called Default Port Configurations, the default port value > for mcast-port is not quite correct. It says the default is 10334. It > should instead say that the default is 0 when the locators property is set, > and 10334 when the locators property is not set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260122#comment-17260122 ] ASF GitHub Bot commented on GEODE-8800: --- gesterzhou merged pull request #5879: URL: https://github.com/apache/geode/pull/5879 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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 > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-8800. -- Fix Version/s: 1.14.0 Resolution: Fixed > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8800) SSL is supposed to disable slower receiver feature
[ https://issues.apache.org/jira/browse/GEODE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260123#comment-17260123 ] ASF subversion and git services commented on GEODE-8800: Commit 17b7911f521c20087591853f1bfb0417cc7047e2 in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=17b7911 ] GEODE-8800: Slower receiver is not allowed with cluster TLS/SSL (#5879) Co-authored-by: Xiaojian Zhou Co-authored-by: Bill Burcham > SSL is supposed to disable slower receiver feature > -- > > Key: GEODE-8800 > URL: https://issues.apache.org/jira/browse/GEODE-8800 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > According to document, slow receiver options are disabled in systems using > SSL > (https://geode.apache.org/docs/guide/12/managing/monitor_tune/slow_receivers_managing.html). > > But TLS tests found it did not. If the cluster specified > async-distribution-timeout to 1 aggressively, it will cause SSL test to hang. > When distribution took longer than async-distribution-timeout, even d-ack > region will be using async message queue, which conflicts with SSL. > > There're 2 alternatives to fix: > (1) if SSL is enabled, and detected asyncDistributionTimeout>0, throw > exception. > (2) if SSL is enabled, force asyncDistributionTimeout to be 0 even it > configed >0. > We decide to take alternative-(1). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8815) Cache could close with uncaught exception
Jianxia Chen created GEODE-8815:
---
Summary: Cache could close with uncaught exception
Key: GEODE-8815
URL: https://issues.apache.org/jira/browse/GEODE-8815
Project: Geode
Issue Type: Bug
Reporter: Jianxia Chen
In GemFireCacheImpl.initialize(), it is possible that an uncaught exception is
logged and close the cache.
{code:java}
try {
if (!isClient) {
applyJarAndXmlFromClusterConfig();
}
initializeDeclarativeCache();
completedCacheXml = true;
} catch (RuntimeException e) {
logger.error("Cache initialization for " + this.toString() + " failed
because:", e);
throw e;
} finally {
if (!completedCacheXml) {
// so initializeDeclarativeCache threw an exception
try {
close();
} catch (Throwable ignore) {
// I don't want init to throw an exception that came from the close.
// I want it to throw the original exception that came from
initializeDeclarativeCache.
}
configurationResponse = null;
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8815) Cache could close with uncaught exception
[
https://issues.apache.org/jira/browse/GEODE-8815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen updated GEODE-8815:
Description:
In GemFireCacheImpl.initialize(), it is possible that an uncaught exception is
not logged and close the cache.
{code:java}
try {
if (!isClient) {
applyJarAndXmlFromClusterConfig();
}
initializeDeclarativeCache();
completedCacheXml = true;
} catch (RuntimeException e) {
logger.error("Cache initialization for " + this.toString() + " failed
because:", e);
throw e;
} finally {
if (!completedCacheXml) {
// so initializeDeclarativeCache threw an exception
try {
close();
} catch (Throwable ignore) {
// I don't want init to throw an exception that came from the close.
// I want it to throw the original exception that came from
initializeDeclarativeCache.
}
configurationResponse = null;
}
{code}
was:
In GemFireCacheImpl.initialize(), it is possible that an uncaught exception is
logged and close the cache.
{code:java}
try {
if (!isClient) {
applyJarAndXmlFromClusterConfig();
}
initializeDeclarativeCache();
completedCacheXml = true;
} catch (RuntimeException e) {
logger.error("Cache initialization for " + this.toString() + " failed
because:", e);
throw e;
} finally {
if (!completedCacheXml) {
// so initializeDeclarativeCache threw an exception
try {
close();
} catch (Throwable ignore) {
// I don't want init to throw an exception that came from the close.
// I want it to throw the original exception that came from
initializeDeclarativeCache.
}
configurationResponse = null;
}
{code}
> Cache could close with uncaught exception
> -
>
> Key: GEODE-8815
> URL: https://issues.apache.org/jira/browse/GEODE-8815
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> In GemFireCacheImpl.initialize(), it is possible that an uncaught exception
> is not logged and close the cache.
> {code:java}
> try {
> if (!isClient) {
> applyJarAndXmlFromClusterConfig();
> }
> initializeDeclarativeCache();
> completedCacheXml = true;
> } catch (RuntimeException e) {
> logger.error("Cache initialization for " + this.toString() + " failed
> because:", e);
> throw e;
> } finally {
> if (!completedCacheXml) {
> // so initializeDeclarativeCache threw an exception
> try {
> close();
> } catch (Throwable ignore) {
> // I don't want init to throw an exception that came from the close.
> // I want it to throw the original exception that came from
> initializeDeclarativeCache.
> }
> configurationResponse = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8815) Cache could close with uncaught exception
[
https://issues.apache.org/jira/browse/GEODE-8815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen reassigned GEODE-8815:
---
Assignee: Jianxia Chen
> Cache could close with uncaught exception
> -
>
> Key: GEODE-8815
> URL: https://issues.apache.org/jira/browse/GEODE-8815
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
>
> In GemFireCacheImpl.initialize(), it is possible that an uncaught exception
> is not logged and close the cache.
> {code:java}
> try {
> if (!isClient) {
> applyJarAndXmlFromClusterConfig();
> }
> initializeDeclarativeCache();
> completedCacheXml = true;
> } catch (RuntimeException e) {
> logger.error("Cache initialization for " + this.toString() + " failed
> because:", e);
> throw e;
> } finally {
> if (!completedCacheXml) {
> // so initializeDeclarativeCache threw an exception
> try {
> close();
> } catch (Throwable ignore) {
> // I don't want init to throw an exception that came from the close.
> // I want it to throw the original exception that came from
> initializeDeclarativeCache.
> }
> configurationResponse = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8815) Cache could close with uncaught exception
[
https://issues.apache.org/jira/browse/GEODE-8815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260149#comment-17260149
]
ASF GitHub Bot commented on GEODE-8815:
---
jchen21 opened a new pull request #5882:
URL: https://github.com/apache/geode/pull/5882
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, check Concourse 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 to 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
> Cache could close with uncaught exception
> -
>
> Key: GEODE-8815
> URL: https://issues.apache.org/jira/browse/GEODE-8815
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
>
> In GemFireCacheImpl.initialize(), it is possible that an uncaught exception
> is not logged and close the cache.
> {code:java}
> try {
> if (!isClient) {
> applyJarAndXmlFromClusterConfig();
> }
> initializeDeclarativeCache();
> completedCacheXml = true;
> } catch (RuntimeException e) {
> logger.error("Cache initialization for " + this.toString() + " failed
> because:", e);
> throw e;
> } finally {
> if (!completedCacheXml) {
> // so initializeDeclarativeCache threw an exception
> try {
> close();
> } catch (Throwable ignore) {
> // I don't want init to throw an exception that came from the close.
> // I want it to throw the original exception that came from
> initializeDeclarativeCache.
> }
> configurationResponse = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8815) Cache could close with uncaught exception
[
https://issues.apache.org/jira/browse/GEODE-8815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8815:
--
Labels: pull-request-available (was: )
> Cache could close with uncaught exception
> -
>
> Key: GEODE-8815
> URL: https://issues.apache.org/jira/browse/GEODE-8815
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: pull-request-available
>
> In GemFireCacheImpl.initialize(), it is possible that an uncaught exception
> is not logged and close the cache.
> {code:java}
> try {
> if (!isClient) {
> applyJarAndXmlFromClusterConfig();
> }
> initializeDeclarativeCache();
> completedCacheXml = true;
> } catch (RuntimeException e) {
> logger.error("Cache initialization for " + this.toString() + " failed
> because:", e);
> throw e;
> } finally {
> if (!completedCacheXml) {
> // so initializeDeclarativeCache threw an exception
> try {
> close();
> } catch (Throwable ignore) {
> // I don't want init to throw an exception that came from the close.
> // I want it to throw the original exception that came from
> initializeDeclarativeCache.
> }
> configurationResponse = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
