[jira] [Created] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
Jakov Varenina created GEODE-10123: -- Summary: Multiple execution of Create region command results with duplicated region in cluster configuration Key: GEODE-10123 URL: https://issues.apache.org/jira/browse/GEODE-10123 Project: Geode Issue Type: Bug Reporter: Jakov Varenina -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[ https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10123: -- Labels: needsTriage (was: ) > Multiple execution of Create region command results with duplicated region in > cluster configuration > --- > > Key: GEODE-10123 > URL: https://issues.apache.org/jira/browse/GEODE-10123 > Project: Geode > Issue Type: Bug >Reporter: Jakov Varenina >Priority: Major > Labels: needsTriage > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[ https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10123: --- Labels: needsTriage pull-request-available (was: needsTriage) > Multiple execution of Create region command results with duplicated region in > cluster configuration > --- > > Key: GEODE-10123 > URL: https://issues.apache.org/jira/browse/GEODE-10123 > Project: Geode > Issue Type: Bug >Reporter: Jakov Varenina >Priority: Major > Labels: needsTriage, pull-request-available > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[ https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakov Varenina reassigned GEODE-10123: -- Assignee: Jakov Varenina > Multiple execution of Create region command results with duplicated region in > cluster configuration > --- > > Key: GEODE-10123 > URL: https://issues.apache.org/jira/browse/GEODE-10123 > Project: Geode > Issue Type: Bug >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > Labels: needsTriage, pull-request-available > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the same "create region" command executes more
than once successfully during servers restart and results in the duplicated
definition of the same region in the cluster configuration. When this happens,
servers throw the following exception at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is sometimes unreliable
during restarts, as it takes some time for the locator to accumulate this
information. It makes more sense to perform required checks against cluster
configuration stored on locators when using cluster configuration.
> Multiple execution of Create region command results with duplicated region in
> cluster configuration
> ---
>
> Key: GEODE-10123
> URL: https://issues.apache.org/jira/browse/GEODE-10123
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> We have observed that sometimes the same "create region" command executes
> more than once successfully during servers restart and results in the
> duplicated definition of the same region in the cluster configuration. When
> this happens, servers throw the following exception at startup:
> {code:java}
> Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
> parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
> while parsing XML.
> org.apache.geode.cache.RegionExistsException: /regionTest
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
> at
> org.apache.geode.distributed.ServerL
[jira] [Resolved] (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
]
Donal Evans resolved GEODE-10010.
-
Resolution: Fixed
> 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, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> 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=17507012#comment-17507012
]
ASF subversion and git services commented on GEODE-10010:
-
Commit be028f2343ec0a8eb3dc031d0b0796f6cc6ef846 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=be028f2 ]
GEODE-10010: Refine per-second Redis stats (#7437)
Code changes:
- Rather than a value that updates once per second, instantaneous
operations per second and instantaneous kilobytes read per second now
return a rolling average of those stats updated 16 times per second
- Change instantaneous operations per second type from double to int,
since it's always a whole number
- Introduce RollingAverageStat nested class in RedisStats to handle
calculating the rolling average value of a given stat
Test changes:
- Rename AbstractRedisInfoStatsIntegrationTest to match child classes
- Rather than retrieving instantaneous per second stats after
operations have finished, sample them while operations are ongoing
- Assert only that the stats have updated, not that they are close to a
calculated expected value, as this proved too inconsistent and very
flaky
- Use default duration for await() in connected clients stat test to
prevent flakiness
Authored-by: Donal Evans
> 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, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> 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] [Resolved] (GEODE-9708) Clean up FunctionCommandsDistributedTestBase
[ https://issues.apache.org/jira/browse/GEODE-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-9708. Fix Version/s: 1.16.0 Resolution: Fixed > Clean up FunctionCommandsDistributedTestBase > - > > Key: GEODE-9708 > URL: https://issues.apache.org/jira/browse/GEODE-9708 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9694) Remove deprecated elements from QueryCommandDUnitTestBase
[ https://issues.apache.org/jira/browse/GEODE-9694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-9694. Fix Version/s: 1.16.0 Resolution: Fixed > Remove deprecated elements from QueryCommandDUnitTestBase > - > > Key: GEODE-9694 > URL: https://issues.apache.org/jira/browse/GEODE-9694 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9950) Implement LRANGE
[ https://issues.apache.org/jira/browse/GEODE-9950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristen resolved GEODE-9950. Fix Version/s: 1.16.0 Resolution: Fixed > Implement LRANGE > > > Key: GEODE-9950 > URL: https://issues.apache.org/jira/browse/GEODE-9950 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > Implement the LRANGE command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8411) CI Failure: Jetty9CachingClientServerTest. containersShouldShareDataRemovals() fails with comparison failure
[
https://issues.apache.org/jira/browse/GEODE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507116#comment-17507116
]
Geode Integration commented on GEODE-8411:
--
Seen in [distributed-test-openjdk8
#1403|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1403]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0136/test-results/distributedTest/1647054193/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0136/test-artifacts/1647054193/distributedtestfiles-openjdk8-1.16.0-build.0136.tgz].
> CI Failure: Jetty9CachingClientServerTest.
> containersShouldShareDataRemovals() fails with comparison failure
>
>
> Key: GEODE-8411
> URL: https://issues.apache.org/jira/browse/GEODE-8411
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Assignee: Benjamin P Ross
>Priority: Major
>
> We saw Jetty9CachingClientServerTest fail with a Comparison failure in a CI
> run.
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> containersShouldShareDataRemovals FAILED
> org.junit.ComparisonFailure: expected:<"[]"> but was:<"[Foo]">
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10104) Create parallel gateway sender with dispatcher-threads value greater then 1 is failing
[
https://issues.apache.org/jira/browse/GEODE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivanac resolved GEODE-10104.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> Create parallel gateway sender with dispatcher-threads value greater then 1
> is failing
> --
>
> Key: GEODE-10104
> URL: https://issues.apache.org/jira/browse/GEODE-10104
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.14.0
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> When creating parallel gateway sender with attribute dispatcher-threads
> greater then 1, command is rejected with error "{color:#6a8759}Must specify
> --order-policy when --dispatcher-threads is larger than 1.{color}".
>
> But according to documentation:
> You cannot configure the {{order-policy}} for a parallel event queue, because
> parallel queues cannot preserve event ordering for regions. Only the ordering
> of events for a given partition (or in a given queue of a distributed region)
> can be preserved.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10104) Create parallel gateway sender with dispatcher-threads value greater then 1 is failing
[
https://issues.apache.org/jira/browse/GEODE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507118#comment-17507118
]
ASF subversion and git services commented on GEODE-10104:
-
Commit 15d48829a01c0f7ffa970e51ed81ab9492d94640 in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=15d4882 ]
GEODE-10104: allow create gateway sender command with dispatch threads for
parallel sender (#7421)
> Create parallel gateway sender with dispatcher-threads value greater then 1
> is failing
> --
>
> Key: GEODE-10104
> URL: https://issues.apache.org/jira/browse/GEODE-10104
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.14.0
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> When creating parallel gateway sender with attribute dispatcher-threads
> greater then 1, command is rejected with error "{color:#6a8759}Must specify
> --order-policy when --dispatcher-threads is larger than 1.{color}".
>
> But according to documentation:
> You cannot configure the {{order-policy}} for a parallel event queue, because
> parallel queues cannot preserve event ordering for regions. Only the ordering
> of events for a given partition (or in a given queue of a distributed region)
> can be preserved.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8140) Ability to set the scope of a replicated region using gfsh and describe must display scope
[ https://issues.apache.org/jira/browse/GEODE-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507133#comment-17507133 ] ASF subversion and git services commented on GEODE-8140: Commit 671c9f5943cc87d00ad7c5d1e7d9d6b6c12f1fb5 in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=671c9f5 ] GEODE-8140: Set scope field in gfsh. (#7387) * create region now includes a new field called scope to set the scope * This field is only valid for Replicated Regions. * describe region for replicated regions will now display the scope too. > Ability to set the scope of a replicated region using gfsh and describe must > display scope > -- > > Key: GEODE-8140 > URL: https://issues.apache.org/jira/browse/GEODE-8140 > Project: Geode > Issue Type: Task > Components: docs, gfsh >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > * Right now if we are create RR using gfsh and want to set scope, we have to > create region using gfsh, export config , modify the config and restart the > server. > * Fix to include a scope field in create region in gfsh while creating a RR > region > * describe region will also now display the scope. Previously the default > values are not displayed -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-8140) Ability to set the scope of a replicated region using gfsh and describe must display scope
[ https://issues.apache.org/jira/browse/GEODE-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-8140. Fix Version/s: 1.16.0 Resolution: Fixed > Ability to set the scope of a replicated region using gfsh and describe must > display scope > -- > > Key: GEODE-8140 > URL: https://issues.apache.org/jira/browse/GEODE-8140 > Project: Geode > Issue Type: Task > Components: docs, gfsh >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > * Right now if we are create RR using gfsh and want to set scope, we have to > create region using gfsh, export config , modify the config and restart the > server. > * Fix to include a scope field in create region in gfsh while creating a RR > region > * describe region will also now display the scope. Previously the default > values are not displayed -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10104) Create parallel gateway sender with dispatcher-threads value greater then 1 is failing
[
https://issues.apache.org/jira/browse/GEODE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10104:
-
Fix Version/s: 1.16.0
(was: 1.15.0)
> Create parallel gateway sender with dispatcher-threads value greater then 1
> is failing
> --
>
> Key: GEODE-10104
> URL: https://issues.apache.org/jira/browse/GEODE-10104
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.14.0
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> When creating parallel gateway sender with attribute dispatcher-threads
> greater then 1, command is rejected with error "{color:#6a8759}Must specify
> --order-policy when --dispatcher-threads is larger than 1.{color}".
>
> But according to documentation:
> You cannot configure the {{order-policy}} for a parallel event queue, because
> parallel queues cannot preserve event ordering for regions. Only the ordering
> of events for a given partition (or in a given queue of a distributed region)
> can be preserved.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10092) IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client
[ https://issues.apache.org/jira/browse/GEODE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507219#comment-17507219 ] ASF subversion and git services commented on GEODE-10092: - Commit 68f2c633accb2be8be9164830190a1f8ebcf1fae in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=68f2c63 ] GEODE-10092: cleanup unused code (#7441) > IllegalArgumentException: Illegal Capacity (with a negative value) thrown > from EntriesSet.toArray() in client > - > > Key: GEODE-10092 > URL: https://issues.apache.org/jira/browse/GEODE-10092 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > In some case, we see the following stack trace when executing > entriesSet.toArray() call: Exception java.lang.IllegalArgumentException: > Illegal Capacity: -40 > at java.util.ArrayList.(ArrayList.java:157) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:251) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:245) > looks like the entriesSet.size() call will sometimes returns a negative value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
[ https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507220#comment-17507220 ] ASF subversion and git services commented on GEODE-10097: - Commit 2554f42b925f2b9b8ca7eee14c7a887436b1d9db in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2554f42 ] GEODE-10097: Avoid Thread.sleep for reauthentication in MessageDispatcher (#7416) > Do not use Thread.sleep in MessageDispatcher for re-authentication feature > -- > > Key: GEODE-10097 > URL: https://issues.apache.org/jira/browse/GEODE-10097 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > MessageDispatcher uses Thread.sleep and wakes up intervals to recheck > authorization to see if new subject has re-logged in or not, if not, it will > call "authorize" again and again till timeout. Suggest using "wait/notify" > mechanism to wait for the subject to be updated, this way we don't use > Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
[ https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507222#comment-17507222 ] ASF subversion and git services commented on GEODE-10097: - Commit 75c586677c946c47241c06771b53ed18313f9ffc in geode's branch refs/heads/support/1.15 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=75c5866 ] GEODE-10097: Avoid Thread.sleep for reauthentication in MessageDispatcher (#7416) (cherry picked from commit 2554f42b925f2b9b8ca7eee14c7a887436b1d9db) > Do not use Thread.sleep in MessageDispatcher for re-authentication feature > -- > > Key: GEODE-10097 > URL: https://issues.apache.org/jira/browse/GEODE-10097 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > MessageDispatcher uses Thread.sleep and wakes up intervals to recheck > authorization to see if new subject has re-logged in or not, if not, it will > call "authorize" again and again till timeout. Suggest using "wait/notify" > mechanism to wait for the subject to be updated, this way we don't use > Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-7732) CI Failure: JMXMBeanReconnectDUnitTest.serverMXBeansOnLocatorAreRestoredAfterCrashedServerReturns failed
[
https://issues.apache.org/jira/browse/GEODE-7732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507239#comment-17507239
]
Geode Integration commented on GEODE-7732:
--
Seen in [distributed-test-openjdk8
#203|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/203]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0137/test-results/distributedTest/1647374819/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0137/test-artifacts/1647374819/distributedtestfiles-openjdk8-1.16.0-build.0137.tgz].
> CI Failure:
> JMXMBeanReconnectDUnitTest.serverMXBeansOnLocatorAreRestoredAfterCrashedServerReturns
> failed
>
>
> Key: GEODE-7732
> URL: https://issues.apache.org/jira/browse/GEODE-7732
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.12.0
>Reporter: Eric Shu
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Fix For: 1.13.0
>
>
> This failed @
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1487
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.JMXMBeanReconnectDUnitTest$$Lambda$209/0x000840bb5c40.call
> in VM 2 running on Host e8b6d1c09a6c with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.setUp(JMXMBeanReconnectDUnitTest.java:177)
> 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:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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
> or
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507243#comment-17507243 ] ASF subversion and git services commented on GEODE-10100: - Commit 1f4daa25d694a1050dc45ffa7bd72f3715d909dc in geode's branch refs/heads/support/1.13 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1f4daa2 ] GEODE-10100: update Dockerfile to apache-geode 1.13.8 The Dockerfile is updated _after_ the release is already tagged, because it needs to embed the sha256 of the release > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507244#comment-17507244 ] ASF subversion and git services commented on GEODE-10100: - Commit 2fe1464771696065c60c59830d941fedac229c2a in geode-native's branch refs/heads/support/1.13 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=2fe1464 ] GEODE-10100: Update Dockerfile and vars Native client hardcodes Geode version to test with in several places. Update native Dockerfile and other variables to apache-geode 1.13.8 > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507245#comment-17507245 ] ASF subversion and git services commented on GEODE-10100: - Commit ea783016b775e45f59ca17bc08a40d90921ffa4f in geode's branch refs/heads/support/1.13 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ea78301 ] GEODE-10100: Replace 1.13.7 with 1.13.8 as old version Replace 1.13.7 with 1.13.8 in old versions on support/1.13 to enable rolling upgrade tests from 1.13.8 The serialization version has not changed between 1.13.7 and 1.13.8, so there should be no need to keep both > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10100: --- Labels: pull-request-available (was: ) > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507246#comment-17507246 ] ASF subversion and git services commented on GEODE-10100: - Commit 0b6c611e8b7a3f4d3ffdc22c9458ae2a741d1dca in geode's branch refs/heads/support/1.13 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0b6c611 ] GEODE-10100: Bump version to 1.13.9 As part of the Geode Release Process, the build number must be rolled forward so work can begin on the next release > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507249#comment-17507249 ] ASF subversion and git services commented on GEODE-10100: - Commit cb0cbf19ab24b70ff2fc0ae4ef988fafcff8b4a6 in geode-benchmarks's branch refs/heads/support/1.13 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=cb0cbf1 ] GEODE-10100: Bump version to 1.13.9 As part of the Geode Release Process, the geode-benchmarks build number must be rolled forward as work begins on the next release > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507248#comment-17507248 ] ASF subversion and git services commented on GEODE-10100: - Commit c3c6529f19948cd8981b5eeae126220ff8a474f2 in geode-examples's branch refs/heads/support/1.13 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=c3c6529 ] GEODE-10100: Bump version to 1.13.9 As part of the Geode Release Process, the geode-examples build number must be rolled forward as work begins on the next release > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507247#comment-17507247 ] ASF subversion and git services commented on GEODE-10100: - Commit 0706ec5f97cb8a28be959a806810eb382c54cd8a in geode-examples's branch refs/heads/support/1.13 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=0706ec5 ] Revert "GEODE-10100: Set temporary staging repo" The staging repo no longest exists, so set this back to search the default location (mavencentral) > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
[ https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10097. - Fix Version/s: 1.15.0 1.16.0 Assignee: Jinmei Liao Resolution: Fixed > Do not use Thread.sleep in MessageDispatcher for re-authentication feature > -- > > Key: GEODE-10097 > URL: https://issues.apache.org/jira/browse/GEODE-10097 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > MessageDispatcher uses Thread.sleep and wakes up intervals to recheck > authorization to see if new subject has re-logged in or not, if not, it will > call "authorize" again and again till timeout. Suggest using "wait/notify" > mechanism to wait for the subject to be updated, this way we don't use > Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9451) On demand authentication expiration and re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9451. Resolution: Fixed > On demand authentication expiration and re-authentication > - > > Key: GEODE-9451 > URL: https://issues.apache.org/jira/browse/GEODE-9451 > Project: Geode > Issue Type: New Feature > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > This is to implement the feature proposed in this RFC > https://cwiki.apache.org/confluence/display/GEODE/On+Demand+Geode+Authentication+Expiration+and+Re-authentication -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10091) Benchmark instability in RedisZaddAndZremBenchmark
[
https://issues.apache.org/jira/browse/GEODE-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507256#comment-17507256
]
Geode Integration commented on GEODE-10091:
---
Seen in [benchmark-radish
#200|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/200].
> Benchmark instability in RedisZaddAndZremBenchmark
> --
>
> Key: GEODE-10091
> URL: https://issues.apache.org/jira/browse/GEODE-10091
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Eric Zoerner
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> RedisGetBenchmark avg ops/sec
> Baseline:428358.55 Test:446241.49 Difference: +4.2%
> avg latency
> Baseline: 1678809.55 Test: 1611045.34 Difference: -4.0%
> RedisHgetBenchmark avg ops/sec
> Baseline:438535.25 Test:441078.97 Difference: +0.6%
> avg latency
> Baseline: 1638968.92 Test: 1630999.16 Difference: -0.5%
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:191331.54 Test:186806.37 Difference: -2.4%
> avg latency
> Baseline: 3759694.09 Test: 3850396.04 Difference: +2.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:308079.41 Test:303715.78 Difference: -1.4%
> avg latency
> Baseline: 2332102.91 Test: 2367639.93 Difference: +1.5%
> RedisSetBenchmark avg ops/sec
> Baseline:318147.74 Test:326996.22 Difference: +2.8%
> avg latency
> Baseline: 2263687.57 Test: 2198181.68 Difference: -2.9%
> RedisWeightedHsetAndHgetBenchmark avg ops/sec
> Baseline:390383.79 Test:385565.48 Difference: -1.2%
> avg latency
> Baseline: 1842561.96 Test: 1864716.09 Difference: +1.2%
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:375078.82 Test:350886.03 Difference: -6.5%
> avg latency
> Baseline: 1917476.15 Test: 2049452.87 Difference: +6.9%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:124763.60 Test:118600.72 Difference: -4.9%
> avg latency
> Baseline: 5766048.34 Test: 6065491.13 Difference: +5.2%
> RedisZaddBenchmark avg ops/sec
> Baseline:432494.29 Test:438594.53 Difference: +1.4%
> avg latency
> Baseline: 1662639.09 Test: 1639906.18 Difference: -1.4%
> RedisZrangeBenchmark avg ops/sec
> Baseline:295523.77 Test:340381.87 Difference: +15.2%
> avg latency
> Baseline: 2433250.54 Test: 2112961.66 Difference: -13.2%
> RedisZrangeByScoreBenchmark avg ops/sec
> Baseline:285836.33 Test:356142.91 Difference: +24.6%
> avg latency
> Baseline: 2515708.23 Test: 2019249.68 Difference: -19.7%
> This is ITERATION 2 of benchmarking against baseline.
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:358570.33 Test:348012.02 Difference: -2.9%
> avg latency
> Baseline: 2005804.05 Test: 2066535.24 Difference: +3.0%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:122900.38 Test:115226.22 Difference: -6.2%
> avg latency
> Baseline: 5858357.13 Test: 6243018.38 Difference: +6.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:125677.36 Test:118359.94 Difference: -5.8%
> a
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507258#comment-17507258 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk11 #199|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/199] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0140/test-results/distributedTest/1647384403/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0140/test-artifacts/1647384403/distributedtestfiles-openjdk11-1.16.0-build.0140.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10124) Refactor Geode-DUnit as a Class Library
Wayne created GEODE-10124: - Summary: Refactor Geode-DUnit as a Class Library Key: GEODE-10124 URL: https://issues.apache.org/jira/browse/GEODE-10124 Project: Geode Issue Type: Improvement Components: redis Reporter: Wayne Refactor Dunit so that it can be used as a standalone class library. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10125) Refactor Redis to Use Public DataSerializable Framework
Wayne created GEODE-10125: - Summary: Refactor Redis to Use Public DataSerializable Framework Key: GEODE-10125 URL: https://issues.apache.org/jira/browse/GEODE-10125 Project: Geode Issue Type: Improvement Components: redis Reporter: Wayne Refactor Redis to use the public DataSerializable framework instead of the DataSerializableFixedId serialization framework. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10126) Refactor Configuration To Use System Properties
Wayne created GEODE-10126: - Summary: Refactor Configuration To Use System Properties Key: GEODE-10126 URL: https://issues.apache.org/jira/browse/GEODE-10126 Project: Geode Issue Type: Improvement Components: redis Reporter: Wayne The properties currently being used by the Redis module are defined in Geode core. These properties need to be removed from Geode core and refactored to system properties. Validators must also be added for the system properties to ensure that users provide correct values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10122: --- Labels: pull-request-available (was: ) > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.13.7, 1.14.3, 1.15.0, 1.16.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: pull-request-available > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10092) IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client
[ https://issues.apache.org/jira/browse/GEODE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507281#comment-17507281 ] ASF subversion and git services commented on GEODE-10092: - Commit b683e1d47948a4f43f089e8b43ff9647b0324d8e in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b683e1d ] GEODE-10092: cleanup unnecessary method arguments (#7445) > IllegalArgumentException: Illegal Capacity (with a negative value) thrown > from EntriesSet.toArray() in client > - > > Key: GEODE-10092 > URL: https://issues.apache.org/jira/browse/GEODE-10092 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > In some case, we see the following stack trace when executing > entriesSet.toArray() call: Exception java.lang.IllegalArgumentException: > Illegal Capacity: -40 > at java.util.ArrayList.(ArrayList.java:157) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:251) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:245) > looks like the entriesSet.size() call will sometimes returns a negative value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507320#comment-17507320
]
Nabarun Nag commented on GEODE-10119:
-
I am hitting the issue with JDK17
Command to run test:
{code:java}
GRADLE_JVM=/home/nnag/Development/OpenJDK8U-jdk_x64_linux_hotspot_8u282b08/jdk8u282-b08
JAVA_TEST_PATH=/home/nnag/Downloads/OpenJDK17U-jdk_x64_linux_hotspot_17.0.2_8/jdk-17.0.2+8
./gradlew -D--add-exports java.base/jdk.internal.misc=ALL-UN
NAMED
-PcompileJVM=/home/nnag/Development/OpenJDK8U-jdk_x64_linux_hotspot_8u282b08/jdk8u282-b08
-PcompileJVMVer=8 --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
-PtestJVM=/home/nnag/Downloads/OpenJDK17U-jdk_x64_linux_hotspot_17.0.2_8/jdk-17.0.2+8
-PtestJVMVer=11 -x javadoc -x spotlessCheck -x rat
"geode-wan":"distributedTest" --tests
"WANSSLDUnitTest.testSenderSSLReceiverNoSSL*"
{code}
Issue:
{code:java}
[fatal 2022/03/15 19:37:47.723 PDT
tid=56] Uncaught exception in thread Thread[P2P handshake
reader@2767a271-1,5,RMI Runtime]
java.lang.IllegalAccessError: class
org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
@0xb3d7190) cannot access class sun.nio.ch.DirectBuffer (in module java.base)
because module java.base does not export sun.nio.ch to unnamed module @0xb3d7190
at
org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
at
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:332)
at
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:307)
at
org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:214)
at
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:295)
at
org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
at
org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
at
org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833) {code}
Could you share the steps to run the test in JDK16
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> 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-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.g
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507342#comment-17507342 ] ASF subversion and git services commented on GEODE-10100: - Commit 2fe5703543ffaece70ea8161f0fb5d81ed3ee78d in geode's branch refs/heads/support/1.14 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2fe5703 ] GEODE-10100: Replace 1.13.7 with 1.13.8 as old version Replace 1.13.7 with 1.13.8 in old versions on support/1.14 to enable rolling upgrade tests from 1.13.8 The serialization version has not changed between 1.13.7 and 1.13.8, so there should be no need to keep both (cherry picked from commit ea783016b775e45f59ca17bc08a40d90921ffa4f) > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507343#comment-17507343 ] ASF subversion and git services commented on GEODE-10100: - Commit fc017c1776b6a71cf602c0149bbcb82c5b159cce in geode's branch refs/heads/support/1.15 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fc017c1 ] GEODE-10100: Replace 1.13.7 with 1.13.8 as old version Replace 1.13.7 with 1.13.8 in old versions on support/1.15 to enable rolling upgrade tests from 1.13.8 The serialization version has not changed between 1.13.7 and 1.13.8, so there should be no need to keep both (cherry picked from commit ea783016b775e45f59ca17bc08a40d90921ffa4f) (cherry picked from commit 2fe5703543ffaece70ea8161f0fb5d81ed3ee78d) > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10100. -- Fix Version/s: 1.12.10 1.13.9 1.14.5 1.15.0 1.16.0 Resolution: Fixed > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0, 1.16.0 > > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507357#comment-17507357 ] ASF subversion and git services commented on GEODE-10100: - Commit f2b9b903b9878d715b1ccb4382cb57549018d290 in geode's branch refs/heads/develop from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f2b9b90 ] GEODE-10100: Replace 1.13.7 with 1.13.8 as old version (#7447) Replace 1.13.7 with 1.13.8 in old versions on develop to enable rolling upgrade tests from 1.13.8 The serialization version has not changed between 1.13.7 and 1.13.8, so there should be no need to keep both > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0, 1.16.0 > > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
