[jira] [Created] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
Alberto Gomez created GEODE-10008: - Summary: Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region Key: GEODE-10008 URL: https://issues.apache.org/jira/browse/GEODE-10008 Project: Geode Issue Type: Bug Components: gfsh, wan Reporter: Alberto Gomez When the wan-copy region command is executed over a partitioned region, it is possible that sometimes an EntryDestroyedException error is found if, while reading the entries from the region, one of them is destroyed. The error has been seen sometimes when running the following test: WanCopyRegionCommandDUnitTest. testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). Log of the error: Multiple Failures (2 failures) org.opentest4j.AssertionFailedError: [ Member | Status | Message -- | -- | --- alberto-dell(421543):41010 | ERROR | Execution failed. Error: org.apache.geode.cache.EntryDestroyedException: 26 alberto-dell(421504):41009 | OK | Entries copied: 2,977 alberto-dell(421598):41011 | OK | Entries copied: 3,042 ] expected: OK but was: ERROR java.lang.AssertionError: Suspicious strings were written to the log during this run. Fix the strings or use IgnoredException.addIgnoredException to ignore. --- Found suspect string in 'dunit_suspect-vm6.log' at line 1883 [error 2022/02/01 08:58:59.046 CET tid=99] Exception occurred attempting to wan-copy region java.util.concurrent.ExecutionException: org.apache.geode.cache.EntryDestroyedException: 26 at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) at org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) at org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) at org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) at org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) at org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) at org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) at java.lang.Thread.run(Thread.java:748) Caused by: org.apache.geode.cache.EntryDestroyedException: 26 at org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) at org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) at org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) at java.util.HashMap.hash(HashMap.java:340) at java.util.HashMap.put(HashMap.java:613) at java.util.HashSet.add(HashSet.java:220) at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) at java.util.Iterator.forEachRemaining(Iterator.java:116) at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272) at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1580) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566) at org.apache.geode.management.internal.cli.functions.WanCopyRegionFunctionDelegate.getEntries(WanCopyRegionFunctionDelegate.java:193) at org.apache.geode.management.internal.cli.functions.WanCopyRegionFunctionDelegate.wanCopyRegion(WanCopyRegionFunctionDelegate.java:104) at org.apache.geode.
[jira] [Updated] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
[ https://issues.apache.org/jira/browse/GEODE-10008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10008: -- Labels: needsTriage (was: ) > Avoid possible EntryDestroyedException error in wan-copy region command when > entry destroyed in partitioned region > -- > > Key: GEODE-10008 > URL: https://issues.apache.org/jira/browse/GEODE-10008 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > When the wan-copy region command is executed over a partitioned region, it is > possible that sometimes an EntryDestroyedException error is found if, while > reading the entries from the region, one of them is destroyed. > The error has been seen sometimes when running the following test: > WanCopyRegionCommandDUnitTest. > testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). > > Log of the error: > Multiple Failures (2 failures) > org.opentest4j.AssertionFailedError: [ Member | > Status | Message > -- | -- | > --- > alberto-dell(421543):41010 | ERROR | Execution failed. Error: > org.apache.geode.cache.EntryDestroyedException: 26 > alberto-dell(421504):41009 | OK | Entries copied: 2,977 > alberto-dell(421598):41011 | OK | Entries copied: 3,042 > ] > expected: OK > but was: ERROR > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm6.log' at line 1883 > [error 2022/02/01 08:58:59.046 CET tid=99] > Exception occurred attempting to wan-copy region > java.util.concurrent.ExecutionException: > org.apache.geode.cache.EntryDestroyedException: 26 > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) > at > org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.apache.geode.cache.EntryDestroyedException: 26 > at > org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) > at > org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) > at > org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) > at java.util.HashMap.hash(HashMap.java:340) > at java.util.HashMap.put(HashMap.java:613) > at java.util.HashSet.add(HashSet.java:220) > at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at > java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) > at > java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272) > at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1580) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) > at > java.util.stream.ReduceOps$ReduceOp.evalua
[jira] [Assigned] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
[ https://issues.apache.org/jira/browse/GEODE-10008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-10008: - Assignee: Alberto Gomez > Avoid possible EntryDestroyedException error in wan-copy region command when > entry destroyed in partitioned region > -- > > Key: GEODE-10008 > URL: https://issues.apache.org/jira/browse/GEODE-10008 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > When the wan-copy region command is executed over a partitioned region, it is > possible that sometimes an EntryDestroyedException error is found if, while > reading the entries from the region, one of them is destroyed. > The error has been seen sometimes when running the following test: > WanCopyRegionCommandDUnitTest. > testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). > > Log of the error: > Multiple Failures (2 failures) > org.opentest4j.AssertionFailedError: [ Member | > Status | Message > -- | -- | > --- > alberto-dell(421543):41010 | ERROR | Execution failed. Error: > org.apache.geode.cache.EntryDestroyedException: 26 > alberto-dell(421504):41009 | OK | Entries copied: 2,977 > alberto-dell(421598):41011 | OK | Entries copied: 3,042 > ] > expected: OK > but was: ERROR > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm6.log' at line 1883 > [error 2022/02/01 08:58:59.046 CET tid=99] > Exception occurred attempting to wan-copy region > java.util.concurrent.ExecutionException: > org.apache.geode.cache.EntryDestroyedException: 26 > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) > at > org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.apache.geode.cache.EntryDestroyedException: 26 > at > org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) > at > org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) > at > org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) > at java.util.HashMap.hash(HashMap.java:340) > at java.util.HashMap.put(HashMap.java:613) > at java.util.HashSet.add(HashSet.java:220) > at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at > java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) > at > java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272) > at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1580) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) > at > java.util.s
[jira] [Commented] (GEODE-9969) The region name starting with underscore lead to missing disk store after restart
[
https://issues.apache.org/jira/browse/GEODE-9969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485296#comment-17485296
]
ASF subversion and git services commented on GEODE-9969:
Commit b7da7c25032aa921a73de3141c240b78849c334e in geode's branch
refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Ray Ingles
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b7da7c2 ]
Revert "GEODE-9969: Fix unescaping the region name with underscore (#7282)"
(#7311)
This reverts commit 4b5b30e379c35f17578251fe297c2b7fe7921fa4 for breaking
windows-acceptance-test. Please re-submit this as a new PR and add the
`Windows` label to run Windows checks too.
Co-authored-by: Ray Ingles
> The region name starting with underscore lead to missing disk store after
> restart
> -
>
> Key: GEODE-9969
> URL: https://issues.apache.org/jira/browse/GEODE-9969
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.12.8, 1.13.6, 1.14.2, 1.15.0
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> The problem is when using the region with a name starting with an
> underscore(allowed by documentation
> [region_naming|https://geode.apache.org/docs/guide/114/basic_config/data_regions/region_naming.html]).
> If we stop one of the members and then rename the working dir(include disk
> store dir) to some new name and start the server with the name like renamed
> working dir, it will lead that we have the same disk-store-id in the listed
> disk-stores and in the missing disk store.
> This happens only if we are using the region with an underscore at the
> beginning.
> Steps to reproduce:
> Run locator and 4 servers, create region with name starting by underscore
> # start locator --name=locator
> # start server --name=server1 --server-port=40401
> # start server --name=server2 --server-port=40402
> # start server --name=server3 --server-port=40403
> # start server --name=server4 --server-port=40404
> # create region --name=_test-region --type=PARTITION_REDUNDANT_PERSISTENT
> --redundant-copies=1 --total-num-buckets=10 --enable-synchronous-disk=false
> # query --query="select * from /_test-region"
> From another terminal (Kill server and rename working dir)
> # kill -9 $(cat server4/vf.gf.server.pid)
> # mv server4/ server5
> {code:java}
> gfsh>list disk-stores
> Member Name | Member Id | Disk Store Name | Disk
> Store ID
> --- | -- | --- |
>
> server1 | 192.168.0.145(server1:16916):41001 | DEFAULT |
> d5d17b43-4a06-408b-917f-08e5b2533ebe
> server2 | 192.168.0.145(server2:17004):41002 | DEFAULT |
> 31d47cb4-718e-4b58-bde3-ae15b4657910
> server3 | 192.168.0.145(server3:17094):41003 | DEFAULT |
> f12850c6-a73b-443e-9ee0-87f0819ae6bc
> server5 | 192.168.0.145(server5:17428):41004 | DEFAULT |
> 7a552fb3-e43d-4fa8-baa8-f6dc794cbf74
> gfsh>show missing-disk-stores
> Missing Disk Stores
> Disk Store ID | Host | Directory
> | - |
>
> 7a552fb3-e43d-4fa8-baa8-f6dc794cbf74 | 192.168.0.145 |
> /home/mkevo/apache-geode-1.15.0-build.0/bin/server4/.
> No missing colocated region found
> {code}
> Start a new server with a name like you rename your working dir from the
> restarted server.
> # start server --name=server5 --server-port=40405
> Now we have the following output:
> {code:java}
> gfsh>list disk-stores
> Member Name | Member Id| Disk Store Name | Disk
> Store ID
> --- | -- | --- |
>
> server1 | 192.168.0.145(server1:16916):41001 | DEFAULT |
> d5d17b43-4a06-408b-917f-08e5b2533ebe
> server2 | 192.168.0.145(server2:17004):41002 | DEFAULT |
> 31d47cb4-718e-4b58-bde3-ae15b4657910
> server3 | 192.168.0.145(server3:17094):41003 | DEFAULT |
> f12850c6-a73b-443e-9ee0-87f0819ae6bc
> server5 | 192.168.0.145(server5:17428):41004 | DEFAULT |
> 7a552fb3-e43d-4fa8-baa8-f6dc794cbf74
> gfsh>show missing-disk-stores
> Missing Disk Stores
>Disk Store ID | Host | Directory
> | - |
>
> 7a552fb3-e43d-4fa8-baa8-f6dc794cbf74 | 192.168.0.145 |
> /home/mkevo/apache-geode-1.15.0-build.0/bin/server4/.
> No missing colocated region foun
[jira] [Commented] (GEODE-9972) remove 'wait overnight' step from release process
[ https://issues.apache.org/jira/browse/GEODE-9972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485297#comment-17485297 ] ASF subversion and git services commented on GEODE-9972: Commit bbe12c3217aa351422f3a61aa9a2cd1546a7b5db in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bbe12c3 ] GEODE-9972: eliminate overnight step from release process (#7280) * eliminate overnight step from release process and template announce mail * remove duplicate Subject line * fix group name in link * support branch protection for develop on all subprojects * make sure we can still pull after changing the single-branch-develop checkouts to support branches * fix undefined variable usage > remove 'wait overnight' step from release process > - > > Key: GEODE-9972 > URL: https://issues.apache.org/jira/browse/GEODE-9972 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > now that maven central syncs within 1 hour and closer.cgi mirrors use the new > dlcdn which syncs within 15 minutes, we can eliminate the overnight step in > the release steps -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9853) Optimize number of ParallelQueueRemovalMessage sent for dropped events in large clusters
[ https://issues.apache.org/jira/browse/GEODE-9853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485298#comment-17485298 ] ASF subversion and git services commented on GEODE-9853: Commit bbe9a3acf2f0812ef733dfe74f07fb9412c886e3 in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bbe9a3a ] GEODE-9853: get all members hosting bucket (#7144) * GEODE-9853: get all members hosting bucket > Optimize number of ParallelQueueRemovalMessage sent for dropped events in > large clusters > > > Key: GEODE-9853 > URL: https://issues.apache.org/jira/browse/GEODE-9853 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > In multi site cluster (16 or more servers), in case we stop gw sender, and > continue to put new entries in region, it is observed large number of > ParallelQueueRemovalMessage sent. > It seems that this can be optimized, since most of sent messages are ignored > by most of other servers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485302#comment-17485302
]
ASF subversion and git services commented on GEODE-9995:
Commit 00ccce2a652e6fe21b8af8a162cff35ab47f036c in geode's branch
refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=00ccce2 ]
GEODE-9995: Use ephemeral ports to avoid port in use issues (#7329)
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: backport, needsTriage, pull-request-available
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9988) Log full exception when JNDI binding fails during cache creation
[
https://issues.apache.org/jira/browse/GEODE-9988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485300#comment-17485300
]
ASF subversion and git services commented on GEODE-9988:
Commit e0c4b9c5c7a69ae59992f2a571aace1199cca8a8 in geode's branch
refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e0c4b9c ]
GEODE-9988: Log full exception when JNDI binding fails during cache creation
(#7304)
> Log full exception when JNDI binding fails during cache creation
>
>
> Key: GEODE-9988
> URL: https://issues.apache.org/jira/browse/GEODE-9988
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> When a cache.xml is configured with a {{jndi-binding}} construct it may fail
> to bind but the log does not contain a useful error message, only something
> like:
> {noformat}
> [warn 2022/01/25 13:26:41.286 PST tid=0x1] jndi-binding creation of
> SimpleDataSource failed with:
> org.apache.geode.internal.datasource.DataSourceCreateException: Failed to
> connect to "SimpleDataSource". See log for details {noformat}
> The full exception stack would contain a the real cause of the problem. In
> this case:
> {noformat}
> java.sql.SQLNonTransientConnectionException: java.net.ConnectException :
> Error connecting to server localhost on port 1,528 with message Connection
> refused (Connection refused).
> at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
> at
> org.apache.geode.internal.datasource.GemFireBasicDataSource.getConnection(GemFireBasicDataSource.java:111)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.getConnection(JNDIInvoker.java:429)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.validateAndBindDataSource(JNDIInvoker.java:413)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:392)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:366)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:3064)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3485)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:226)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2007)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:881)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1784)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2969)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:113)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:507)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:867)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:796)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:142)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:644)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:328)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:196)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:233)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4203)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1625)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1451)
> at
> org.apache.geode.i
[jira] [Commented] (GEODE-9892) Create Infrastructure for Redis Lists
[ https://issues.apache.org/jira/browse/GEODE-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485303#comment-17485303 ] ASF subversion and git services commented on GEODE-9892: Commit 7cd92335160fe0127fb7f984cc8d4dfa5f266d7f in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7cd9233 ] Merge branch 'develop' into GEODE-9892-Create-Infrastructure-for-Redis-Lists > Create Infrastructure for Redis Lists > - > > Key: GEODE-9892 > URL: https://issues.apache.org/jira/browse/GEODE-9892 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > > Create the infrastructure for supporting Redis Lists including: > * Use of the appropriate underlying Java collection > * Implementing the [LPUSH|https://redis.io/commands/lpush] Command > * Implementing the [LRANGE|https://redis.io/commands/lrange] command > +Acceptance Critera+ > The LPUSH and LRANGE commands have been implemented with appropriate unit > testing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9830) SINTERSTORE Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485299#comment-17485299 ] ASF subversion and git services commented on GEODE-9830: Commit 32e32af84a2727b3589d5940546ccc655a40e69d in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Kris10 [ https://gitbox.apache.org/repos/asf?p=geode.git;h=32e32af ] GEODE-9830: SINTERSTORE Command Support (#7302) > SINTERSTORE Command Supported > - > > Key: GEODE-9830 > URL: https://issues.apache.org/jira/browse/GEODE-9830 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The SINTERSTORE command has been implemented but lacks sufficient testing to > ensure that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9604) Fix test in MSetDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485301#comment-17485301
]
ASF subversion and git services commented on GEODE-9604:
Commit 06879926eb34afa69c739b70c2314370d285c64a in geode's branch
refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Eric Zoerner
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0687992 ]
GEODE-9604 Also fix MSetNXDunitTest (#7325)
> Fix test in MSetDUnitTest
> -
>
> Key: GEODE-9604
> URL: https://issues.apache.org/jira/browse/GEODE-9604
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> The tests {{testMSet_crashDoesNotLeaveInconsistencies}} and
> {{testMSetnx_crashDoesNotLeaveInconsistencies}} in {{MSetDunitTest}} and
> {{MSetnxDUnitTest}} respectively, do not pass under stress and will
> occasionally fail. This may be due to a product issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9835) SSCAN Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485384#comment-17485384 ] ASF subversion and git services commented on GEODE-9835: Commit da6043239eb637994eaba64c3d59cf327aac0f7d in geode's branch refs/heads/develop from Bala Kaza Venkata [ https://gitbox.apache.org/repos/asf?p=geode.git;h=da60432 ] GEODE-9835: Add SSCAN to Redis supported commands (#7278) Co-authored-by: Bala Kaza Venkata Co-authored-by: Steve Sienkowski > SSCAN Command Supported > --- > > Key: GEODE-9835 > URL: https://issues.apache.org/jira/browse/GEODE-9835 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Wayne >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The SSCAN command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9835) SSCAN Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9835. Fix Version/s: 1.16.0 Resolution: Fixed > SSCAN Command Supported > --- > > Key: GEODE-9835 > URL: https://issues.apache.org/jira/browse/GEODE-9835 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Wayne >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > The SSCAN command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9835) SSCAN Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-9835: --- Fix Version/s: 1.15.0 > SSCAN Command Supported > --- > > Key: GEODE-9835 > URL: https://issues.apache.org/jira/browse/GEODE-9835 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Wayne >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The SSCAN command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9835) SSCAN Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485408#comment-17485408 ] ASF subversion and git services commented on GEODE-9835: Commit 3f56bd36a698f05ade37fa0eaa629dfaacf5148f in geode's branch refs/heads/support/1.15 from Bala Kaza Venkata [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f56bd3 ] GEODE-9835: Add SSCAN to Redis supported commands (#7278) Co-authored-by: Bala Kaza Venkata Co-authored-by: Steve Sienkowski (cherry picked from commit da6043239eb637994eaba64c3d59cf327aac0f7d) > SSCAN Command Supported > --- > > Key: GEODE-9835 > URL: https://issues.apache.org/jira/browse/GEODE-9835 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Wayne >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The SSCAN command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9835) SSCAN Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne reassigned GEODE-9835: Assignee: Steve Sienkowski > SSCAN Command Supported > --- > > Key: GEODE-9835 > URL: https://issues.apache.org/jira/browse/GEODE-9835 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Wayne >Assignee: Steve Sienkowski >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The SSCAN command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) and even loaded as such by via the _Java_ {{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such by via the
> _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the HTTP service hosting the Geode
> provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
> API). Of course, these Web apps need to be updated as well (to use the new
> Jakarta EE 9 specs).
> There are other examples of the SPI used on Apache Geode, which are part of
> the non-internal, public API, for example the
> [ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
> inte
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such by via the
> _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the HTTP service hosting the Geode
> provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
> API). Of course, these Web apps need to be updated as well (to use the new
> Jakarta EE 9 specs).
> Ther
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the HTTP service hosting the Geode provided Web apps
(e.g. Pulse, Management/Admin REST API, Developer REST API). Of course, these
Web apps need to be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such by via the
> _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
> Geode p
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used inn Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such by via the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of the SPI used on Apache Geode, which are part of the
non-internal, public API, for example the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such by via the
> _Java_ {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstra
[jira] [Updated] (GEODE-10006) Do not configure Geode JTA transaction management by default
[ https://issues.apache.org/jira/browse/GEODE-10006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10006: -- Priority: Critical (was: Major) > Do not configure Geode JTA transaction management by default > > > Key: GEODE-10006 > URL: https://issues.apache.org/jira/browse/GEODE-10006 > Project: Geode > Issue Type: Improvement >Reporter: John Blum >Priority: Critical > > Geode's built-in JTA transaction management and JNDI context registrations > are unnecessary unless Apache Geode is being used in the context of JTA > transactions (along with other JTA transactional compliant resources that > must all be associated with the same logical transaction) in the first place. > JTA is an overly complex application architectural design, is error prone to > use correctly at best, and with the advent of Microservices, has become > increasingly unpopular for managing consistency across 2 or more > transactional resources. > Additionally, Apache Geode's transaction manager should never be used as the > JTA transaction manager implementation. > The logic to initiate JTA transactional logic in Apache Geode resides in the > [JNDIInvoker|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/jndi/JNDIInvoker.java] > class and > [initiated|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L875](specifically, > > [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L964]) > during cache creation and initialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485002#comment-17485002
]
John Blum edited comment on GEODE-10005 at 2/1/22, 7:25 PM:
Part of the requirement to upgrade *Eclipse Jetty* in Apache Geode in order to
release SBDG {{2.0}} stems from *Eclipse Jetty's* support of *Jakarta EE 9*,
replacing the old _Java EE 8_ specifications (see
[here|https://eclipse-foundation.blog/2021/03/24/eclipse-jetty-11-supports-the-big-bang/]
and
[here|https://containerjournal.com/features/jetty-project-embraces-jakarta-ee-9-specification/]).
was (Author: jblum):
Part of the requirement to upgrade *Eclipse Jetty* in Apache Geode in order to
release SBDG {{2.0}} stems from *Eclipse Jetty's* support of *Jakarta EE 9*,
replacing the old _Java EE 8_ (see
[here|https://eclipse-foundation.blog/2021/03/24/eclipse-jetty-11-supports-the-big-bang/]
and
[here|https://containerjournal.com/features/jetty-project-embraces-jakarta-ee-9-specification/]).
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Blocker
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-7381) PDX Serialization throws an Exception with an incorrect error message when a domain type does not have a public, no-arg constructor
[
https://issues.apache.org/jira/browse/GEODE-7381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964234#comment-16964234
]
John Blum edited comment on GEODE-7381 at 2/1/22, 7:29 PM:
---
Technically, there is no logical reason why the constructor needs to be public
in the first place. Java Introspection & Reflection facilities allow all
members of a class type to be inspected *and* invoked.
Also there is no reason why the constructor needs to be no-arg either. See
[GEODE-7382].
was (Author: jblum):
Technically, there is not logical reason why the constructor needs to be public
in the first place. Java Introspection & Reflection facilities allow all
members of a class type to be inspected *and* invoked.
Also there is no reason why the constructor needs to be no-arg either. See
[GEODE-7382].
> PDX Serialization throws an Exception with an incorrect error message when a
> domain type does not have a public, no-arg constructor
> ---
>
> Key: GEODE-7381
> URL: https://issues.apache.org/jira/browse/GEODE-7381
> Project: Geode
> Issue Type: Bug
>Reporter: John Blum
>Priority: Major
>
> Apache Geode throws an incorrect {{PdxSerializationException}} with message
> "_Could not deserialize pdx because the pdx serializer's fromData returned
> false for a pdx of class com.springone.austin.vursys.battle.model.Vote_",
> instead.
> The Stack Trace is:
> {code:java}
> Caused by: org.apache.geode.pdx.PdxSerializationException: Could not
> deserialize pdx because the pdx serializer's fromData returned false for a
> pdx of class com.springone.austin.vursys.battle.model.Vote
> at
> org.apache.geode.pdx.internal.PdxReaderImpl.basicGetObject(PdxReaderImpl.java:823)
> at
> org.apache.geode.pdx.internal.PdxReaderImpl.getObject(PdxReaderImpl.java:753)
> at
> org.apache.geode.internal.InternalDataSerializer.readPdxSerializable(InternalDataSerializer.java:3153)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2916)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:90)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2013)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2006)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:132)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1336)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)
> at
> org.apache.geode.internal.cache.LocalDataSet$LocalEntriesSet$LocalEntriesSetIterator.moveNext(LocalDataSet.java:781)
> at
> org.apache.geode.internal.cache.LocalDataSet$LocalEntriesSet$LocalEntriesSetIterator.(LocalDataSet.java:735)
> at
> org.apache.geode.internal.cache.LocalDataSet$LocalEntriesSet.iterator(LocalDataSet.java:722)
> at
> org.apache.geode.cache.query.internal.ResultsCollectionWrapper.iterator(ResultsCollectionWrapper.java:199)
> at
> org.apache.geode.cache.query.internal.QRegion.iterator(QRegion.java:282)
> at
> org.apache.geode.cache.query.internal.CompiledSelect.doNestedIterations(CompiledSelect.java:834)
> at
> org.apache.geode.cache.query.internal.CompiledSelect.doIterationEvaluate(CompiledSelect.java:701)
> at
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:545)
> at
> org.apache.geode.cache.query.internal.CompiledGroupBySelect.evaluate(CompiledGroupBySelect.java:157)
> at
> org.apache.geode.cache.query.internal.CompiledGroupBySelect.evaluate(CompiledGroupBySelect.java:42)
> at
> org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:430)
> at
> org.apache.geode.internal.cache.PRQueryProcessor.executeQueryOnBuckets(PRQueryProcessor.java:246)
> at
> org.apache.geode.internal.cache.PRQueryProcessor.executeSequentially(PRQueryProcessor.java:204)
> at
> org.apache.geode.internal.cache.PRQueryProcessor.executeQuery(PRQueryProcessor.java:122)
> at
> org.apache.geode.internal.cache.PartitionedRegionQueryEvaluator.executeQueryOnLocalNode(PartitionedRegionQueryEvaluator.java:962)
> at
> org.apache.geode.internal.cache.PartitionedRegionQueryEvaluator.executeQueryOnRemoteAndLocalNodes(PartitionedRegionQueryEvaluator.java:378)
> at
> org.apache.geode.internal.cache.PartitionedRegionQueryEvaluator.queryBuckets(PartitionedRegionQueryEvaluator.java:495)
>
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:51 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always provided a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users. For one, it
unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always provided a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX u
[jira] [Commented] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485434#comment-17485434
]
John Blum commented on GEODE-7394:
--
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users. For one, it
unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always provided a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
> Gfsh `configure pdx` command is non-intuitive and currently has a bad user
> experience
> -
>
> Key: GEODE-7394
> URL: https://issues.apache.org/jira/browse/GEODE-7394
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
>
> The _Gfsh_ {{configure pdx}} command does *not* register a {{PdxSerializer}}
> (e.g. {{ReflectionBasedAutoSerializer}}, or otherwise) unless the
> {{--auto-serializable-classes}} option is explicitly specified. Without a
> {{PdxSerializer}} the command essentially serves no purpose nor has any
> effect. Effectively, the command is useless.
> For example, doing something like `gfsh> configure pdx
> --read-serialized=false` or `gfsh> configure pdx --ignore-unread-fields` by
> itself is *pointless* since ultimately there would be no `PdxSerializer`
> registered in this case.
> _Gfsh_ should minimally register a `PdxSerializer` anytime the `configure
> pdx` command is used regardless of the options provided, especially if it
> returns successfully without incident. For instance, it could register the
> `ReflectionBaseAutoSerializer` with the REGEX {{.*}} (de/serializing all
> types, regardless of whether that is optimal or not).
> Alternatively, if we decide not to register the
> {{ReflectionBasedAutoSerialier}} with a generic REGEX (e.g. {{.*}}), then we
> should _fail-fast_ and the command should report that
> {{--[portable-]-auto-serializable-classes}} is required!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:52 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always provided a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REG
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:53 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGE
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:53 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
simple typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REG
[jira] [Comment Edited] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:54 PM:
---
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
simple typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can compose multiple (chained) {{Predicates}}
together, which effectively simplifies (separates) expressions and/or matching
criteria, making it easier to test.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
simple typo in the pattern can co
[jira] [Updated] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7891:
-
Description:
The following properties in [GemFire
Properties|https://geode.apache.org/docs/guide/114/reference/topics/gemfire_properties.html]
are *NOT* valid (distributed system/config properties) according to the
[ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
and
[DistributionConfig|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
classes!
Properties include:
{code:java}
"geode.disallow-internal-messages-without-credentials"
"tombstone-gc-threshold"
{code}
was:
The following properties in [GemFire
Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html]
are *NOT* valid (distributed system/config properties) according to the
[ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
and
[DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
classes!
Properties include:
{code:java}
"geode.disallow-internal-messages-without-credentials"
"tombstone-gc-threshold"
{code}
> User Guide refers to non-valid GemFire Properties
> -
>
> Key: GEODE-7891
> URL: https://issues.apache.org/jira/browse/GEODE-7891
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: John Blum
>Priority: Major
>
> The following properties in [GemFire
> Properties|https://geode.apache.org/docs/guide/114/reference/topics/gemfire_properties.html]
> are *NOT* valid (distributed system/config properties) according to the
> [ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
> and
> [DistributionConfig|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
> classes!
> Properties include:
> {code:java}
> "geode.disallow-internal-messages-without-credentials"
> "tombstone-gc-threshold"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485450#comment-17485450
]
John Blum commented on GEODE-7891:
--
Given the lack of action / comments on this ticket, I am not sure we are
understanding the gravity of the situation here.
By declaring these properties in {{gemfire.properties}}, Apache Geode will fail
to start (!) as they are considered invalid properties.
For example, given the following test application code using the Apache Geode
API:
{code:java}
public class ApacheGeodePeerCacheApplication {
public static void main(String[] args) {
Cache peerCache = new CacheFactory()
.set("name", "PeerCacheApplicationTest")
.set("tombstone-gc-threshold", "100")
.create();
assertThat(peerCache).isNotNull();
assertThat(peerCache.getName()).isEqualTo("PeerCacheApplicationTest");
}
}
{code}
Running this test application results in the following error:
{code}
Exception in thread "main" java.lang.IllegalArgumentException: Unknown
configuration attribute name tombstone-gc-threshold. Valid attribute names are:
ack-severe-alert-threshold ack-wait-threshold archive-disk-space-limit
archive-file-size-limit async-distribution-timeout async-max-queue-size
async-queue-timeout bind-address cache-xml-file cluster-configuration-dir
cluster-ssl-ciphers cluster-ssl-enabled cluster-ssl-keystore
cluster-ssl-keystore-password cluster-ssl-keystore-type cluster-ssl-protocols
cluster-ssl-require-authentication cluster-ssl-truststore
cluster-ssl-truststore-password compatible-with-redis-bind-address
compatible-with-redis-enabled compatible-with-redis-password
compatible-with-redis-port conflate-events conserve-sockets delta-propagation
deploy-working-dir disable-auto-reconnect disable-jmx disable-tcp
distributed-system-id distributed-transactions durable-client-id
durable-client-timeout enable-cluster-configuration
enable-management-rest-service enable-network-partition-detection
enable-time-statistics enforce-unique-host gateway-ssl-ciphers
gateway-ssl-enabled gateway-ssl-keystore gateway-ssl-keystore-password
gateway-ssl-keystore-type gateway-ssl-protocols
gateway-ssl-require-authentication gateway-ssl-truststore
gateway-ssl-truststore-password groups http-service-bind-address
http-service-port http-service-ssl-ciphers http-service-ssl-enabled
http-service-ssl-keystore http-service-ssl-keystore-password
http-service-ssl-keystore-type http-service-ssl-protocols
http-service-ssl-require-authentication http-service-ssl-truststore
http-service-ssl-truststore-password jmx-manager jmx-manager-access-file
jmx-manager-bind-address jmx-manager-hostname-for-clients jmx-manager-http-port
jmx-manager-password-file jmx-manager-port jmx-manager-ssl-ciphers
jmx-manager-ssl-enabled jmx-manager-ssl-keystore
jmx-manager-ssl-keystore-password jmx-manager-ssl-keystore-type
jmx-manager-ssl-protocols jmx-manager-ssl-require-authentication
jmx-manager-ssl-truststore jmx-manager-ssl-truststore-password
jmx-manager-start jmx-manager-update-rate load-cluster-configuration-from-dir
locator-wait-time locators lock-memory log-disk-space-limit log-file
log-file-size-limit log-level max-num-reconnect-tries max-wait-time-reconnect
mcast-address mcast-flow-control mcast-port mcast-recv-buffer-size
mcast-send-buffer-size mcast-ttl member-timeout membership-port-range
memcached-bind-address memcached-port memcached-protocol name
off-heap-memory-size redundancy-zone remote-locators remove-unresponsive-client
roles security-auth-token-enabled-components security-client-accessor
security-client-accessor-pp security-client-auth-init
security-client-authenticator security-client-dhalgo security-log-file
security-log-level security-manager security-peer-auth-init
security-peer-authenticator security-peer-verifymember-timeout
security-post-processor security-shiro-init security-udp-dhalgo
serializable-object-filter server-bind-address server-ssl-ciphers
server-ssl-enabled server-ssl-keystore server-ssl-keystore-password
server-ssl-keystore-type server-ssl-protocols server-ssl-require-authentication
server-ssl-truststore server-ssl-truststore-password socket-buffer-size
socket-lease-time ssl-ciphers ssl-cluster-alias ssl-default-alias
ssl-enabled-components ssl-endpoint-identification-enabled ssl-gateway-alias
ssl-jmx-alias ssl-keystore ssl-keystore-password ssl-keystore-type
ssl-locator-alias ssl-parameter-extension ssl-protocols
ssl-require-authentication ssl-server-alias ssl-truststore
ssl-truststore-password ssl-truststore-type ssl-use-default-context
ssl-web-alias ssl-web-require-authentication start-dev-rest-api start-locator
statistic-archive-file statistic-sample-rate statistic-sampling-enabled
tcp-port thread-monitor-enabled thread
[jira] [Commented] (GEODE-9907) Geode-for-redis example failed with JedisNoReachableClusterNodeException: No reachable node in cluster
[
https://issues.apache.org/jira/browse/GEODE-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485459#comment-17485459
]
Donal Evans commented on GEODE-9907:
Holding off on backporting this fix until it's been proven out on develop for a
little longer, as it's shown to be impossible to reproduce locally and so
difficult to confirm the fix.
> Geode-for-redis example failed with JedisNoReachableClusterNodeException: No
> reachable node in cluster
> --
>
> Key: GEODE-9907
> URL: https://issues.apache.org/jira/browse/GEODE-9907
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: backport, blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
>
> {code:java}
> > Task :geodeForRedis:run FAILED
> Exception in thread "main"
> redis.clients.jedis.exceptions.JedisNoReachableClusterNodeException: No
> reachable node in cluster
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnection(JedisSlotBasedConnectionHandler.java:117)
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnectionFromSlot(JedisSlotBasedConnectionHandler.java:139)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:118)
> at redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.zadd(JedisCluster.java:1106)
> at
> org.apache.geode_examples.geodeForRedis.Example.populateSortedSet(Example.java:53)
> at org.apache.geode_examples.geodeForRedis.Example.main(Example.java:30)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geodeForRedis:run'.
> > Process 'command '/usr/lib/jvm/bellsoft-java8-amd64/bin/java'' finished
> >with non-zero exit value 1
> {code}
>
> This might be related to [https://github.com/apache/geode-examples/pull/110]
> due to the location of the failure of the test
> org.apache.geode_examples.geodeForRedis.Example.main.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-9907) Geode-for-redis example failed with JedisNoReachableClusterNodeException: No reachable node in cluster
[
https://issues.apache.org/jira/browse/GEODE-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485459#comment-17485459
]
Donal Evans edited comment on GEODE-9907 at 2/1/22, 8:27 PM:
-
Holding off on backporting this fix until it's been proven out on develop for a
little longer, as it's shown to be impossible to reproduce locally and
therefore difficult to confirm the fix.
was (Author: donalevans):
Holding off on backporting this fix until it's been proven out on develop for a
little longer, as it's shown to be impossible to reproduce locally and so
difficult to confirm the fix.
> Geode-for-redis example failed with JedisNoReachableClusterNodeException: No
> reachable node in cluster
> --
>
> Key: GEODE-9907
> URL: https://issues.apache.org/jira/browse/GEODE-9907
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: backport, blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
>
> {code:java}
> > Task :geodeForRedis:run FAILED
> Exception in thread "main"
> redis.clients.jedis.exceptions.JedisNoReachableClusterNodeException: No
> reachable node in cluster
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnection(JedisSlotBasedConnectionHandler.java:117)
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnectionFromSlot(JedisSlotBasedConnectionHandler.java:139)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:118)
> at redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.zadd(JedisCluster.java:1106)
> at
> org.apache.geode_examples.geodeForRedis.Example.populateSortedSet(Example.java:53)
> at org.apache.geode_examples.geodeForRedis.Example.main(Example.java:30)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geodeForRedis:run'.
> > Process 'command '/usr/lib/jvm/bellsoft-java8-amd64/bin/java'' finished
> >with non-zero exit value 1
> {code}
>
> This might be related to [https://github.com/apache/geode-examples/pull/110]
> due to the location of the failure of the test
> org.apache.geode_examples.geodeForRedis.Example.main.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9995:
--
Labels: pull-request-available (was: backport needsTriage
pull-request-available)
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9995.
---
Fix Version/s: 1.15.0
1.16.0
Resolution: Fixed
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485470#comment-17485470
]
ASF subversion and git services commented on GEODE-9995:
Commit 55396d4650f5214b27982b43ea7b59d05a23ba55 in geode's branch
refs/heads/support/1.15 from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=55396d4 ]
GEODE-9995: Use ephemeral ports to avoid port in use issues (#7329)
(cherry picked from commit 00ccce2a652e6fe21b8af8a162cff35ab47f036c)
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9958) Add tests that confirm that a geode-for-redis server can be successfully started using gfsh
[
https://issues.apache.org/jira/browse/GEODE-9958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485469#comment-17485469
]
ASF subversion and git services commented on GEODE-9958:
Commit 9f021cf6f6216f9a8db6d395b07b9b74745cf75d in geode's branch
refs/heads/support/1.15 from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9f021cf ]
GEODE-9958: Add gfsh-specific tests for Radish startup (#7297)
(cherry picked from commit 77945531fafd566a0cbca7d05b5347b8ea299efc)
> Add tests that confirm that a geode-for-redis server can be successfully
> started using gfsh
> ---
>
> Key: GEODE-9958
> URL: https://issues.apache.org/jira/browse/GEODE-9958
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> The class {{GeodeRedisServerStartupUsingGfshAcceptanceTest}} has several
> tests that confirm various error cases for starting a geode-for-redis server
> using gfsh, but no test cases that show that a server can successfully be
> started with gfsh, connected to using a client, and successfully execute
> operations.
> Tests should be written to cover the happy-path situation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9993) Redis SMOVE command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9993. Fix Version/s: 1.16.0 Resolution: Fixed > Redis SMOVE command should be atomic > > > Key: GEODE-9993 > URL: https://issues.apache.org/jira/browse/GEODE-9993 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > The [documentation for the SMOVE command|https://redis.io/commands/SMOVE] > states that it is atomic. The current implementation in the geode-for-redis > module is not, which could result in partially-applied moves if servers crash > during a move. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the SMoveExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9993) Redis SMOVE command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485475#comment-17485475 ] ASF subversion and git services commented on GEODE-9993: Commit c0eb58e055a16fd5bc5bb22ad97d88739d55ae02 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c0eb58e ] GEODE-9993: Make SMOVE transactional (#7321) - Use lockedExecuteInTransaction method in SMoveExecutor - Refactor RedisSet.sadd and RedisSet.srem to not modify the list of members passed to them - Do not use Delta in AbstractRedisData.storeChanges() if operation is using a transaction Authored-by: Donal Evans > Redis SMOVE command should be atomic > > > Key: GEODE-9993 > URL: https://issues.apache.org/jira/browse/GEODE-9993 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > The [documentation for the SMOVE command|https://redis.io/commands/SMOVE] > states that it is atomic. The current implementation in the geode-for-redis > module is not, which could result in partially-applied moves if servers crash > during a move. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the SMoveExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9993) Redis SMOVE command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-9993: --- Fix Version/s: 1.15.0 > Redis SMOVE command should be atomic > > > Key: GEODE-9993 > URL: https://issues.apache.org/jira/browse/GEODE-9993 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The [documentation for the SMOVE command|https://redis.io/commands/SMOVE] > states that it is atomic. The current implementation in the geode-for-redis > module is not, which could result in partially-applied moves if servers crash > during a move. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the SMoveExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9993) Redis SMOVE command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485479#comment-17485479 ] ASF subversion and git services commented on GEODE-9993: Commit f7905968b7b89db08c3edf180b91b3fdadfe45b7 in geode's branch refs/heads/support/1.15 from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f790596 ] GEODE-9993: Make SMOVE transactional (#7321) - Use lockedExecuteInTransaction method in SMoveExecutor - Refactor RedisSet.sadd and RedisSet.srem to not modify the list of members passed to them - Do not use Delta in AbstractRedisData.storeChanges() if operation is using a transaction Authored-by: Donal Evans (cherry picked from commit c0eb58e055a16fd5bc5bb22ad97d88739d55ae02) > Redis SMOVE command should be atomic > > > Key: GEODE-9993 > URL: https://issues.apache.org/jira/browse/GEODE-9993 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The [documentation for the SMOVE command|https://redis.io/commands/SMOVE] > states that it is atomic. The current implementation in the geode-for-redis > module is not, which could result in partially-applied moves if servers crash > during a move. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the SMoveExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485497#comment-17485497
]
John Blum commented on GEODE-7891:
--
Additionally...
{code:java}
Exception in thread "main" java.lang.IllegalArgumentException: Unknown
configuration attribute name
geode.disallow-internal-messages-without-credentials. Valid attribute names
are: ack-severe-alert-threshold ack-wait-threshold archive-disk-space-limit
archive-file-size-limit async-distribution-timeout async-max-queue-size
async-queue-timeout bind-address cache-xml-file cluster-configuration-dir
cluster-ssl-ciphers cluster-ssl-enabled cluster-ssl-keystore
cluster-ssl-keystore-password cluster-ssl-keystore-type cluster-ssl-protocols
cluster-ssl-require-authentication cluster-ssl-truststore
cluster-ssl-truststore-password compatible-with-redis-bind-address
compatible-with-redis-enabled compatible-with-redis-password
compatible-with-redis-port conflate-events conserve-sockets delta-propagation
deploy-working-dir disable-auto-reconnect disable-jmx disable-tcp
distributed-system-id distributed-transactions durable-client-id
durable-client-timeout enable-cluster-configuration
enable-management-rest-service enable-network-partition-detection
enable-time-statistics enforce-unique-host gateway-ssl-ciphers
gateway-ssl-enabled gateway-ssl-keystore gateway-ssl-keystore-password
gateway-ssl-keystore-type gateway-ssl-protocols
gateway-ssl-require-authentication gateway-ssl-truststore
gateway-ssl-truststore-password groups http-service-bind-address
http-service-port http-service-ssl-ciphers http-service-ssl-enabled
http-service-ssl-keystore http-service-ssl-keystore-password
http-service-ssl-keystore-type http-service-ssl-protocols
http-service-ssl-require-authentication http-service-ssl-truststore
http-service-ssl-truststore-password jmx-manager jmx-manager-access-file
jmx-manager-bind-address jmx-manager-hostname-for-clients jmx-manager-http-port
jmx-manager-password-file jmx-manager-port jmx-manager-ssl-ciphers
jmx-manager-ssl-enabled jmx-manager-ssl-keystore
jmx-manager-ssl-keystore-password jmx-manager-ssl-keystore-type
jmx-manager-ssl-protocols jmx-manager-ssl-require-authentication
jmx-manager-ssl-truststore jmx-manager-ssl-truststore-password
jmx-manager-start jmx-manager-update-rate load-cluster-configuration-from-dir
locator-wait-time locators lock-memory log-disk-space-limit log-file
log-file-size-limit log-level max-num-reconnect-tries max-wait-time-reconnect
mcast-address mcast-flow-control mcast-port mcast-recv-buffer-size
mcast-send-buffer-size mcast-ttl member-timeout membership-port-range
memcached-bind-address memcached-port memcached-protocol name
off-heap-memory-size redundancy-zone remote-locators remove-unresponsive-client
roles security-auth-token-enabled-components security-client-accessor
security-client-accessor-pp security-client-auth-init
security-client-authenticator security-client-dhalgo security-log-file
security-log-level security-manager security-peer-auth-init
security-peer-authenticator security-peer-verifymember-timeout
security-post-processor security-shiro-init security-udp-dhalgo
serializable-object-filter server-bind-address server-ssl-ciphers
server-ssl-enabled server-ssl-keystore server-ssl-keystore-password
server-ssl-keystore-type server-ssl-protocols server-ssl-require-authentication
server-ssl-truststore server-ssl-truststore-password socket-buffer-size
socket-lease-time ssl-ciphers ssl-cluster-alias ssl-default-alias
ssl-enabled-components ssl-endpoint-identification-enabled ssl-gateway-alias
ssl-jmx-alias ssl-keystore ssl-keystore-password ssl-keystore-type
ssl-locator-alias ssl-parameter-extension ssl-protocols
ssl-require-authentication ssl-server-alias ssl-truststore
ssl-truststore-password ssl-truststore-type ssl-use-default-context
ssl-web-alias ssl-web-require-authentication start-dev-rest-api start-locator
statistic-archive-file statistic-sample-rate statistic-sampling-enabled
tcp-port thread-monitor-enabled thread-monitor-interval-ms
thread-monitor-time-limit-ms udp-fragment-size udp-recv-buffer-size
udp-send-buffer-size use-cluster-configuration user-command-packages
validate-serializable-objects .
at
org.apache.geode.internal.AbstractConfig.checkAttributeName(AbstractConfig.java:333)
at
org.apache.geode.distributed.internal.AbstractDistributionConfig.checkAttributeName(AbstractDistributionConfig.java:728)
at
org.apache.geode.distributed.internal.AbstractDistributionConfig.getAttributeType(AbstractDistributionConfig.java:890)
at
org.apache.geode.internal.AbstractConfig.setAttribute(AbstractConfig.java:222)
at
org.apache.geode.distributed.internal.DistributionConfigImpl.initialize(DistributionConfigImpl.java:1688)
at
org.apache.geode.distributed.internal.DistributionConfigImpl.(Distr
[jira] [Updated] (GEODE-9986) Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
[
https://issues.apache.org/jira/browse/GEODE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9986:
--
Labels: (was: needsTriage)
> Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
> ---
>
> Key: GEODE-9986
> URL: https://issues.apache.org/jira/browse/GEODE-9986
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jens Deppe
>Priority: Major
>
> {code:java}
> > Task :geode-assembly:distributedTest
> StartLocatorCommandDUnitTest > testWithAvailablePort FAILED
> org.opentest4j.AssertionFailedError: [The Locator process terminated
> unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit4212781718034424448/junit8849905322533733269 for full details.
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001
> started at Sat Jan 22 08:31:19 UTC 2022: Message distribution has
> terminated, caused by org.apache.geode.ForcedDisconnectException: Member
> isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2686)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2660)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getOrCreateService(DLockService.java:2641)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.(InternalConfigurationPersistenceService.java:131)
> at
> org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1390)
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:792)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:787)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:768)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:399)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:734)
> at
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:637)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:220)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2319)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.lang.Thread.run(Thread.java:750)
> ]
> expected: OK
> but was: ERROR
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.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.StartLocatorCommandDUnitTest.testWithAvailablePort(StartLocatorCommandDUnitTest.java:219)
> StartLocatorCommandDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 591
> [fatal 2022/01/22 08:31:40.041 UTC
> tid=58] Possible loss of quorum due to the loss of 1 cache processes:
> [heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001]
> ---
> Fo
[jira] [Comment Edited] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485450#comment-17485450
]
John Blum edited comment on GEODE-7891 at 2/1/22, 10:08 PM:
Given the lack of action / comments on this ticket, I am not sure we are
understanding the gravity of the situation here.
By declaring these properties in {{gemfire.properties}}, Apache Geode will fail
to start (!) as they are considered invalid properties.
For example, given the following test application code using the Apache Geode
API:
{code:java}
public class ApacheGeodePeerCacheApplication {
public static void main(String[] args) {
Cache peerCache = new CacheFactory()
.set("name", "PeerCacheApplicationTest")
.set("tombstone-gc-threshold", "100")
.create();
assertThat(peerCache).isNotNull();
assertThat(peerCache.getName()).isEqualTo("PeerCacheApplicationTest");
}
}
{code}
Running this test application results in the following error:
{code}
Exception in thread "main" java.lang.IllegalArgumentException: Unknown
configuration attribute name tombstone-gc-threshold. Valid attribute names are:
ack-severe-alert-threshold ack-wait-threshold archive-disk-space-limit
archive-file-size-limit async-distribution-timeout async-max-queue-size
async-queue-timeout bind-address cache-xml-file cluster-configuration-dir
cluster-ssl-ciphers cluster-ssl-enabled cluster-ssl-keystore
cluster-ssl-keystore-password cluster-ssl-keystore-type cluster-ssl-protocols
cluster-ssl-require-authentication cluster-ssl-truststore
cluster-ssl-truststore-password compatible-with-redis-bind-address
compatible-with-redis-enabled compatible-with-redis-password
compatible-with-redis-port conflate-events conserve-sockets delta-propagation
deploy-working-dir disable-auto-reconnect disable-jmx disable-tcp
distributed-system-id distributed-transactions durable-client-id
durable-client-timeout enable-cluster-configuration
enable-management-rest-service enable-network-partition-detection
enable-time-statistics enforce-unique-host gateway-ssl-ciphers
gateway-ssl-enabled gateway-ssl-keystore gateway-ssl-keystore-password
gateway-ssl-keystore-type gateway-ssl-protocols
gateway-ssl-require-authentication gateway-ssl-truststore
gateway-ssl-truststore-password groups http-service-bind-address
http-service-port http-service-ssl-ciphers http-service-ssl-enabled
http-service-ssl-keystore http-service-ssl-keystore-password
http-service-ssl-keystore-type http-service-ssl-protocols
http-service-ssl-require-authentication http-service-ssl-truststore
http-service-ssl-truststore-password jmx-manager jmx-manager-access-file
jmx-manager-bind-address jmx-manager-hostname-for-clients jmx-manager-http-port
jmx-manager-password-file jmx-manager-port jmx-manager-ssl-ciphers
jmx-manager-ssl-enabled jmx-manager-ssl-keystore
jmx-manager-ssl-keystore-password jmx-manager-ssl-keystore-type
jmx-manager-ssl-protocols jmx-manager-ssl-require-authentication
jmx-manager-ssl-truststore jmx-manager-ssl-truststore-password
jmx-manager-start jmx-manager-update-rate load-cluster-configuration-from-dir
locator-wait-time locators lock-memory log-disk-space-limit log-file
log-file-size-limit log-level max-num-reconnect-tries max-wait-time-reconnect
mcast-address mcast-flow-control mcast-port mcast-recv-buffer-size
mcast-send-buffer-size mcast-ttl member-timeout membership-port-range
memcached-bind-address memcached-port memcached-protocol name
off-heap-memory-size redundancy-zone remote-locators remove-unresponsive-client
roles security-auth-token-enabled-components security-client-accessor
security-client-accessor-pp security-client-auth-init
security-client-authenticator security-client-dhalgo security-log-file
security-log-level security-manager security-peer-auth-init
security-peer-authenticator security-peer-verifymember-timeout
security-post-processor security-shiro-init security-udp-dhalgo
serializable-object-filter server-bind-address server-ssl-ciphers
server-ssl-enabled server-ssl-keystore server-ssl-keystore-password
server-ssl-keystore-type server-ssl-protocols server-ssl-require-authentication
server-ssl-truststore server-ssl-truststore-password socket-buffer-size
socket-lease-time ssl-ciphers ssl-cluster-alias ssl-default-alias
ssl-enabled-components ssl-endpoint-identification-enabled ssl-gateway-alias
ssl-jmx-alias ssl-keystore ssl-keystore-password ssl-keystore-type
ssl-locator-alias ssl-parameter-extension ssl-protocols
ssl-require-authentication ssl-server-alias ssl-truststore
ssl-truststore-password ssl-truststore-type ssl-use-default-context
ssl-web-alias ssl-web-require-authentication start-dev-rest-api start-locator
statistic-archive-file statistic-sample-rate statistic-sampl
[jira] [Commented] (GEODE-9986) Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
[
https://issues.apache.org/jira/browse/GEODE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485509#comment-17485509
]
Jens Deppe commented on GEODE-9986:
---
This is definitely a flaky test issue. Unfortunately it is difficult to fully
debug since the error is being generated from a locator launched by a `gfsh`
invocation. It would be most helpful to see the logs of this invocation but
unfortunately those are not available or visible when the test errors. I have
some ideas on how to address that, but for now I believe it is safe not to
consider this a `blocker`.
> Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
> ---
>
> Key: GEODE-9986
> URL: https://issues.apache.org/jira/browse/GEODE-9986
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jens Deppe
>Priority: Major
>
> {code:java}
> > Task :geode-assembly:distributedTest
> StartLocatorCommandDUnitTest > testWithAvailablePort FAILED
> org.opentest4j.AssertionFailedError: [The Locator process terminated
> unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit4212781718034424448/junit8849905322533733269 for full details.
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001
> started at Sat Jan 22 08:31:19 UTC 2022: Message distribution has
> terminated, caused by org.apache.geode.ForcedDisconnectException: Member
> isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2686)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2660)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getOrCreateService(DLockService.java:2641)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.(InternalConfigurationPersistenceService.java:131)
> at
> org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1390)
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:792)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:787)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:768)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:399)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:734)
> at
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:637)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:220)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2319)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.lang.Thread.run(Thread.java:750)
> ]
> expected: OK
> but was: ERROR
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.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.StartLocatorCommandDUnitTest.testWithAvailablePort(StartLocatorCommandDUnitTest.java:219)
> StartLocatorCommandDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
>
[jira] [Comment Edited] (GEODE-9986) Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
[
https://issues.apache.org/jira/browse/GEODE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485509#comment-17485509
]
Jens Deppe edited comment on GEODE-9986 at 2/1/22, 10:09 PM:
-
This is definitely a flaky test issue. Unfortunately it is difficult to fully
debug since the error is being generated from a locator launched by a {{gfsh}}
invocation. It would be most helpful to see the logs of this invocation but
unfortunately those are not available or visible when the test errors. I have
some ideas on how to address that, but for now I believe it is safe not to
consider this a `blocker`.
was (Author: jens.deppe):
This is definitely a flaky test issue. Unfortunately it is difficult to fully
debug since the error is being generated from a locator launched by a `gfsh`
invocation. It would be most helpful to see the logs of this invocation but
unfortunately those are not available or visible when the test errors. I have
some ideas on how to address that, but for now I believe it is safe not to
consider this a `blocker`.
> Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
> ---
>
> Key: GEODE-9986
> URL: https://issues.apache.org/jira/browse/GEODE-9986
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jens Deppe
>Priority: Major
>
> {code:java}
> > Task :geode-assembly:distributedTest
> StartLocatorCommandDUnitTest > testWithAvailablePort FAILED
> org.opentest4j.AssertionFailedError: [The Locator process terminated
> unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit4212781718034424448/junit8849905322533733269 for full details.
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001
> started at Sat Jan 22 08:31:19 UTC 2022: Message distribution has
> terminated, caused by org.apache.geode.ForcedDisconnectException: Member
> isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2686)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2660)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getOrCreateService(DLockService.java:2641)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.(InternalConfigurationPersistenceService.java:131)
> at
> org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1390)
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:792)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:787)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:768)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:399)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:734)
> at
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:637)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:220)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2319)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.lang.Thread.run(Thread.java:750)
> ]
> expected: OK
> but was: ERROR
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
[jira] [Updated] (GEODE-10009) The CacheClientProxy for a durable client can be terminated when it shouldn't be
[ https://issues.apache.org/jira/browse/GEODE-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10009: -- Labels: needsTriage (was: ) > The CacheClientProxy for a durable client can be terminated when it shouldn't > be > > > Key: GEODE-10009 > URL: https://issues.apache.org/jira/browse/GEODE-10009 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.15.0 >Reporter: Barrett Oglesby >Priority: Major > Labels: needsTriage > > When the client connection is closed but the server has not left or crashed > (e.g in the re-authentication failed case), its possible that two threads in > a durable client can interleave in a way that causes an extra durable task to > be created on the server that eventually causes the CacheClientProxy to be > terminated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10009) The CacheClientProxy for a durable client can be terminated when it shouldn't be
Barrett Oglesby created GEODE-10009: --- Summary: The CacheClientProxy for a durable client can be terminated when it shouldn't be Key: GEODE-10009 URL: https://issues.apache.org/jira/browse/GEODE-10009 Project: Geode Issue Type: Bug Components: client queues Affects Versions: 1.15.0 Reporter: Barrett Oglesby When the client connection is closed but the server has not left or crashed (e.g in the re-authentication failed case), its possible that two threads in a durable client can interleave in a way that causes an extra durable task to be created on the server that eventually causes the CacheClientProxy to be terminated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10009) The CacheClientProxy for a durable client can be terminated when it shouldn't be
[ https://issues.apache.org/jira/browse/GEODE-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrett Oglesby reassigned GEODE-10009: --- Assignee: Barrett Oglesby > The CacheClientProxy for a durable client can be terminated when it shouldn't > be > > > Key: GEODE-10009 > URL: https://issues.apache.org/jira/browse/GEODE-10009 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.15.0 >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: needsTriage > > When the client connection is closed but the server has not left or crashed > (e.g in the re-authentication failed case), its possible that two threads in > a durable client can interleave in a way that causes an extra durable task to > be created on the server that eventually causes the CacheClientProxy to be > terminated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9738) CI failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable failed with DistributedSystemDisconnectedException
[
https://issues.apache.org/jira/browse/GEODE-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9738:
--
Labels: needsTriage pull-request-available (was: needsTriage)
> CI failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable
> failed with DistributedSystemDisconnectedException
> ---
>
> Key: GEODE-9738
> URL: https://issues.apache.org/jira/browse/GEODE-9738
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Nabarun Nag
>Priority: Major
> Labels: needsTriage, pull-request-available
> Attachments: GEODE-9738-short.log.all, controller.log, locator.log,
> vm0.log, vm1.log, vm2.log, vm3.log
>
>
> {noformat}
> RollingUpgradeRollServersOnReplicatedRegion_dataserializable >
> testRollServersOnReplicatedRegion_dataserializable[from_v1.13.4] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 685[fatal
> 2021/10/14 00:24:14.739 UTC tid=115] Uncaught exception
> in thread Thread[FederatingManager6,5,RMI Runtime]
> org.apache.geode.management.ManagementException:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-10ae5f9d-2528-5e02-b707-d968eb54d50a(vm2:580278:locator):54751
> started at Thu Oct 14 00:23:52 UTC 2021: Message distribution has terminated
> at
> org.apache.geode.management.internal.FederatingManager.addMemberArtifacts(FederatingManager.java:486)
> at
> org.apache.geode.management.internal.FederatingManager$AddMemberTask.call(FederatingManager.java:596)
> at
> org.apache.geode.management.internal.FederatingManager.lambda$addMember$1(FederatingManager.java:199)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-10ae5f9d-2528-5e02-b707-d968eb54d50a(vm2:580278:locator):54751
> started at Thu Oct 14 00:23:52 UTC 2021: Message distribution has terminated
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2885)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5212)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.CreateRegionProcessor.initializeRegion(CreateRegionProcessor.java:121)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1164)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
> at
> org.apache.geode.internal.cache.InternalRegionFactory.create(InternalRegionFactory.java:78)
> at
> org.apache.geode.management.internal.FederatingManager.addMemberArtifacts(FederatingManager.java:429)
> ... 5 more
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:420)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:436)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481)
> at jdk.internal.reflect.GeneratedMethodAccessor11.invoke(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.la
[jira] [Updated] (GEODE-10009) The CacheClientProxy for a durable client can be terminated when it shouldn't be
[ https://issues.apache.org/jira/browse/GEODE-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10009: --- Labels: needsTriage pull-request-available (was: needsTriage) > The CacheClientProxy for a durable client can be terminated when it shouldn't > be > > > Key: GEODE-10009 > URL: https://issues.apache.org/jira/browse/GEODE-10009 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.15.0 >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: needsTriage, pull-request-available > > When the client connection is closed but the server has not left or crashed > (e.g in the re-authentication failed case), its possible that two threads in > a durable client can interleave in a way that causes an extra durable task to > be created on the server that eventually causes the CacheClientProxy to be > terminated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
Kristen created GEODE-10010:
---
Summary: CI: InfoStatsIntegrationTest >
opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
Key: GEODE-10010
URL: https://issues.apache.org/jira/browse/GEODE-10010
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0
Reporter: Kristen
[*http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/*]
{code:java}
> Task :geode-for-redis:integrationTest
InfoStatsIntegrationTest >
opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
java.lang.AssertionError:
Expecting actual:
13.0
to be close to:
19.0
by less than 4.0 but difference was 6.0.
(a difference of exactly 4.0 being considered valid)
at
org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10010:
--
Labels: needsTriage (was: )
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
> Labels: needsTriage
>
> [*http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/*]
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485523#comment-17485523
]
Geode Integration commented on GEODE-10010:
---
Seen on support/1.15 in [integration-test-openjdk8
#6|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-main/jobs/integration-test-openjdk8/builds/6]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-artifacts/1643742213/integrationtestfiles-openjdk8-1.15.0-build.0836.tgz].
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
> Labels: needsTriage
>
> [*http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/*]
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristen updated GEODE-10010:
Description:
http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
{code:java}
> Task :geode-for-redis:integrationTest
InfoStatsIntegrationTest >
opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
java.lang.AssertionError:
Expecting actual:
13.0
to be close to:
19.0
by less than 4.0 but difference was 6.0.
(a difference of exactly 4.0 being considered valid)
at
org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
...{code}
was:
[*http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/*]
{code:java}
> Task :geode-for-redis:integrationTest
InfoStatsIntegrationTest >
opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
java.lang.AssertionError:
Expecting actual:
13.0
to be close to:
19.0
by less than 4.0 but difference was 6.0.
(a difference of exactly 4.0 being considered valid)
at
org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
...{code}
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
> Labels: needsTriage
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-6903) CI Failure: GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection failed with Assertion
[
https://issues.apache.org/jira/browse/GEODE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485524#comment-17485524
]
Geode Integration commented on GEODE-6903:
--
Seen in [integration-test-openjdk11
#137|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk11/builds/137]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0023/test-results/integrationTest/1643750537/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0023/test-artifacts/1643750537/integrationtestfiles-openjdk11-1.16.0-build.0023.tgz].
> CI Failure:
> GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection
> failed with Assertion
>
>
> Key: GEODE-6903
> URL: https://issues.apache.org/jira/browse/GEODE-6903
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.14.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest
> > testExceptionHandlingGetConnection FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[2]>
> at sun.reflect.GeneratedConstructorAccessor26.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection(GemFireTransactionDataSourceIntegrationTest.java:141)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-results/integrationTest/1561170841/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-artifacts/1561170841/integrationtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0399.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9845) CI failure: Multiple tests in OutOfMemoryDUnitTest failed with ConnectException
[
https://issues.apache.org/jira/browse/GEODE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485525#comment-17485525
]
Donal Evans commented on GEODE-9845:
Looking through the logs for this failure, CMS is the garbage collector being
used, as it's the default for Java 8. There is no such thing as a "tenured heap
garbage collector"; the "tenured heap GC" in the logs refers to a collection of
garbage from the tenured heap aka old generation. The reason the JVM memory
usage increases significantly past the configured critical heap percentage may
be that the {{CMSInitiatingOccupancyFraction}} property is not being set to an
appropriate value. From the Javadocs for
{{{}ResourceManager.setCriticalHeapPercentage(){}}}:
{noformat}
* When using this threshold, the VM must be launched with the -Xmx
and
* -Xms switches set to the same values. Many virtual machine
implementations have
* additional VM switches to control the behavior of the garbage collector. We
suggest that you
* investigate tuning the garbage collector when using this type of eviction
controller. A
* collector that frequently collects is needed to keep our heap usage up to
date. In particular,
* on the Sun http://java.sun.com/docs/hotspot/gc/index.html";>HotSpot VM, the
* -XX:+UseConcMarkSweepGC flag needs to be set, and
* -XX:CMSInitiatingOccupancyFraction=N should be set with N being
a percentage that
* is less than the {@link ResourceManager} critical and eviction heap
thresholds.{noformat}
The default value of this property is 65%, which is far greater than the 5%
critical heap percentage used in the test, which will lead to GC not being
triggered until a large portion of the heap has been used up, which in turn
leads to larger, more expensive GCs.
> CI failure: Multiple tests in OutOfMemoryDUnitTest failed with
> ConnectException
> ---
>
> Key: GEODE-9845
> URL: https://issues.apache.org/jira/browse/GEODE-9845
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Priority: Major
> Attachments: PXL_20220114_205141950.MP.jpg,
> PXL_20220114_205147440.jpg, PXL_20220114_205152268.jpg,
> PXL_20220114_205156514.jpg
>
>
> 4 tests in OutOfMemoryDUnitTest failed with `java.net.ConnectException:
> Connection refused`.
> {noformat}
> OutOfMemoryDUnitTest > shouldAllowDeleteOperations_afterThresholdReached
> FAILED
> java.lang.AssertionError:
> Expecting throwable message:
> "No more cluster attempts left."
> to contain:
> "OOM command not allowed"
> but did not.
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisClusterMaxAttemptsException: No more
> cluster attempts left.
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:156)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.set(JedisCluster.java:293)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.setRedisKeyAndValue(OutOfMemoryDUnitTest.java:228)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$addMultipleKeys$5(OutOfMemoryDUnitTest.java:212)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:62)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:877)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.addMultipleKeys(OutOfMemoryDUnitTest.java:210)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillMemory(OutOfMemoryDUnitTest.java:201)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowDeleteOperations_afterThresholdReached(OutOfMemoryDUnitTest.java:166)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(Pare
[jira] [Updated] (GEODE-9958) Add tests that confirm that a geode-for-redis server can be successfully started using gfsh
[
https://issues.apache.org/jira/browse/GEODE-9958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9958:
Fix Version/s: 1.15.0
> Add tests that confirm that a geode-for-redis server can be successfully
> started using gfsh
> ---
>
> Key: GEODE-9958
> URL: https://issues.apache.org/jira/browse/GEODE-9958
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> The class {{GeodeRedisServerStartupUsingGfshAcceptanceTest}} has several
> tests that confirm various error cases for starting a geode-for-redis server
> using gfsh, but no test cases that show that a server can successfully be
> started with gfsh, connected to using a client, and successfully execute
> operations.
> Tests should be written to cover the happy-path situation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales reassigned GEODE-10010:
--
Assignee: Hale Bales
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9929) testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales reassigned GEODE-9929: - Assignee: Hale Bales > testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest > > > Key: GEODE-9929 > URL: https://issues.apache.org/jira/browse/GEODE-9929 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: Kristen >Assignee: Hale Bales >Priority: Major > Labels: needsTriage > > org.apache.geode.internal.cache.RemoteTransactionDUnitTest > > testTXCreationAndCleanupAtCommit FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0 > running on Host 9acb6806d25d with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:473) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565) > Caused by: > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertNotNull(Assert.java:713) > at org.junit.Assert.assertNotNull(Assert.java:723) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595) > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1 > running on Host 9acb6806d25d with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:473) > at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121) > at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182) > Caused by: > java.lang.AssertionError: Event never occurred after 3 ms: > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149) > 8838 tests completed, 1 failed, 458 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10011:
--
Labels: needsTriage (was: )
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire set, but for small set sizes (the set in the failure above
> only has 2 members) it's possible that the first scan will return all
> elements and a cursor value of 0, meaning that the second scan will also
> return all elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
Donal Evans created GEODE-10011:
---
Summary:
SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
is flaky
Key: GEODE-10011
URL: https://issues.apache.org/jira/browse/GEODE-10011
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0, 1.16.0
Reporter: Donal Evans
{noformat}
SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
scanWithNoModificationsDoesNotReturnDuplicates FAILED
java.lang.AssertionError: Property named
'scanWithNoModificationsDoesNotReturnDuplicates' failed (
Expected size: 2 but was: 4 in:
[176, 55, 176, 55]):
With arguments: [[176, 55]]
Original failure message:
Expected size: 2 but was: 4 in:
[55, 202, 55, 202]
First arguments found to also provoke a failure: [[55, 202]]
Seeds for reproduction: [5487908098719980972]
at
org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
Caused by:
java.lang.AssertionError:
Expected size: 2 but was: 4 in:
[55, 202, 55, 202]
at
org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
This failure is due to the test assuming that more than one scan is necessary
to scan the entire set, but for small set sizes (the set in the failure above
only has 2 members) it's possible that the first scan will return all elements
and a cursor value of 0, meaning that the second scan will also return all
elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-10011:
---
Assignee: Donal Evans
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire set, but for small set sizes (the set in the failure above
> only has 2 members) it's possible that the first scan will return all
> elements and a cursor value of 0, meaning that the second scan will also
> return all elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10011:
Labels: (was: needsTriage)
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Priority: Major
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire set, but for small set sizes (the set in the failure above
> only has 2 members) it's possible that the first scan will return all
> elements and a cursor value of 0, meaning that the second scan will also
> return all elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10011:
Description:
{noformat}
SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
scanWithNoModificationsDoesNotReturnDuplicates FAILED
java.lang.AssertionError: Property named
'scanWithNoModificationsDoesNotReturnDuplicates' failed (
Expected size: 2 but was: 4 in:
[176, 55, 176, 55]):
With arguments: [[176, 55]]
Original failure message:
Expected size: 2 but was: 4 in:
[55, 202, 55, 202]
First arguments found to also provoke a failure: [[55, 202]]
Seeds for reproduction: [5487908098719980972]
at
org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
Caused by:
java.lang.AssertionError:
Expected size: 2 but was: 4 in:
[55, 202, 55, 202]
at
org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
This failure is due to the test assuming that more than one scan is necessary
to scan the entire map, but for small map sizes (the map in the failure above
only has 2 keys) it's possible that the first scan will return all elements and
a cursor value of 0, meaning that the second scan will also return all
elements, leading to duplicate elements in the result.
was:
{noformat}
SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
scanWithNoModificationsDoesNotReturnDuplicates FAILED
java.lang.AssertionError: Property named
'scanWithNoModificationsDoesNotReturnDuplicates' failed (
Expected size: 2 but was: 4 in:
[176, 55, 176, 55]):
With arguments: [[176, 55]]
Original failure message:
Expected size: 2 but was: 4 in:
[55, 202, 55, 202]
First arguments found to also provoke a failure: [[55, 202]]
Seeds for reproduction: [5487908098719980972]
at
org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
Caused by:
java.lang.AssertionError:
Expected size: 2 but was: 4 in:
[55, 202, 55, 202]
at
org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
This failure is due to the test assuming that more than one scan is necessary
to scan the entire set, but for small set sizes (the set in the failure above
only has 2 members) it's possible that the first scan will return all elements
and a cursor value of 0, meaning that the second scan will also return all
elements, leading to duplicate elements in the result.
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickC
[jira] [Updated] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10011:
---
Labels: pull-request-available (was: )
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire map, but for small map sizes (the map in the failure above
> only has 2 keys) it's possible that the first scan will return all elements
> and a cursor value of 0, meaning that the second scan will also return all
> elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10001) CI Failure: ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats
[
https://issues.apache.org/jira/browse/GEODE-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485540#comment-17485540
]
Hale Bales commented on GEODE-10001:
Tuesday status update:
Unable to reproduce so far. Based on existing artifacts, I believe that this
was simply a delay in the logs being written, not a failure to write them. That
is why there was a suspicious string written that says the directory wasn't
empty. I think this is a test timing issue, not an issue with Geode.
> CI Failure: ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats
> ---
>
> Key: GEODE-10001
> URL: https://issues.apache.org/jira/browse/GEODE-10001
> Project: Geode
> Issue Type: Bug
> Components: gfsh, logging
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> ExportLogsStatsOverHttpDistributedTest.testExportLogsAndStats has failed with
> missing files in a windows job. It appears that the server 1 logs and stats
> are not there.
> {code:java}
> ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats FAILED
> java.lang.AssertionError:
> Expecting HashSet:
> ["locator-0\\locator-0.log"]
> to contain:
> ["server-1\\server-1.log", "locator-0\\locator-0.log",
> "server-1\\statistics.gfs"]
> but could not find the following element(s):
> ["server-1\\server-1.log", "server-1\\statistics.gfs"]
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsStatsDistributedTestBase.testExportLogsAndStats(ExportLogsStatsDistributedTestBase.java:96)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder$1.evaluate(SerializableTemporaryFolder.java:130)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrch
[jira] [Updated] (GEODE-10012) Avoid retries for non-HA function execution
[
https://issues.apache.org/jira/browse/GEODE-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10012:
--
Labels: needsTriage (was: )
> Avoid retries for non-HA function execution
> ---
>
> Key: GEODE-10012
> URL: https://issues.apache.org/jira/browse/GEODE-10012
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* a cluster with 3 servers and 1 locator
> *AND* a PartitionedRegion with redundant-copies="1"
> *AND* a user-defined Function with isHA=false
> *AND* a geode-native client with a pool with single-hop enabled and retry
> attempts set to 2
> *WHEN* execution fails due to a connectivity issue/connection
> timeout/internal cluster error
> *THEN* function is retried twice
>
> *Additional information.* The function is retried at the network code layer,
> and given whenever there is a timeout/connectivity error, the BSL is removed
> from the ClientMetadataService, whenever retries happen, you might get a
> *InternalFunctionInvocationTargetException* exception thrown indicating:
> {code:java}
> Multiple target nodes found for single hop operation {code}
> Also, have into account that Java client API behaviour never retries a
> Function Execution if isHA=false for that function, and whenever isHA=true,
> the function is retried but on the function execution logic and not at the
> networking layer.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10012) Avoid retries for non-HA function execution
Mario Salazar de Torres created GEODE-10012:
---
Summary: Avoid retries for non-HA function execution
Key: GEODE-10012
URL: https://issues.apache.org/jira/browse/GEODE-10012
Project: Geode
Issue Type: Bug
Components: native client
Reporter: Mario Salazar de Torres
*GIVEN* a cluster with 3 servers and 1 locator
*AND* a PartitionedRegion with redundant-copies="1"
*AND* a user-defined Function with isHA=false
*AND* a geode-native client with a pool with single-hop enabled and retry
attempts set to 2
*WHEN* execution fails due to a connectivity issue/connection timeout/internal
cluster error
*THEN* function is retried twice
*Additional information.* The function is retried at the network code layer,
and given whenever there is a timeout/connectivity error, the BSL is removed
from the ClientMetadataService, whenever retries happen, you might get a
*InternalFunctionInvocationTargetException* exception thrown indicating:
{code:java}
Multiple target nodes found for single hop operation {code}
Also, have into account that Java client API behaviour never retries a Function
Execution if isHA=false for that function, and whenever isHA=true, the function
is retried but on the function execution logic and not at the networking layer.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10012) Avoid retries for non-HA function execution
[
https://issues.apache.org/jira/browse/GEODE-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres reassigned GEODE-10012:
---
Assignee: Mario Salazar de Torres
> Avoid retries for non-HA function execution
> ---
>
> Key: GEODE-10012
> URL: https://issues.apache.org/jira/browse/GEODE-10012
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* a cluster with 3 servers and 1 locator
> *AND* a PartitionedRegion with redundant-copies="1"
> *AND* a user-defined Function with isHA=false
> *AND* a geode-native client with a pool with single-hop enabled and retry
> attempts set to 2
> *WHEN* execution fails due to a connectivity issue/connection
> timeout/internal cluster error
> *THEN* function is retried twice
>
> *Additional information.* The function is retried at the network code layer,
> and given whenever there is a timeout/connectivity error, the BSL is removed
> from the ClientMetadataService, whenever retries happen, you might get a
> *InternalFunctionInvocationTargetException* exception thrown indicating:
> {code:java}
> Multiple target nodes found for single hop operation {code}
> Also, have into account that Java client API behaviour never retries a
> Function Execution if isHA=false for that function, and whenever isHA=true,
> the function is retried but on the function execution logic and not at the
> networking layer.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
