[jira] [Updated] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8950: Labels: blocks-1.15.0 (was: blocks-1.14.0 blocks-1.15.0) > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0 > Fix For: 1.14.0, 1.15.0 > > Attachments: GEODE-8950-before-after-histogram-chart.png, > GEODE-8950-performance degradation vs 1.13.png > > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9029) Initial stub support Redis SLOWLOG command
[ https://issues.apache.org/jira/browse/GEODE-9029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9029: Labels: (was: blocks-1.14.0) > Initial stub support Redis SLOWLOG command > -- > > Key: GEODE-9029 > URL: https://issues.apache.org/jira/browse/GEODE-9029 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Fix For: 1.14.0, 1.15.0 > > > This is used by Redis monitoring tools (e.g. Datadog). A stub implementation > is sufficient; the current implementation will be moved to the Supported > category. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9139:
Fix Version/s: (was: 1.14.0)
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9139:
Labels: blocks-1.14.0 pull-request-available (was: pull-request-available)
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9218) Geode has tests for TLSv1.1 which is disabled by default now
[ https://issues.apache.org/jira/browse/GEODE-9218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-9218. - Fix Version/s: 1.13.3 1.12.3 Resolution: Fixed > Geode has tests for TLSv1.1 which is disabled by default now > > > Key: GEODE-9218 > URL: https://issues.apache.org/jira/browse/GEODE-9218 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.12.3, 1.13.3, 1.14.0, 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0 > > > According to the [Oracle JRE/JDK cryptographic > roadmap|https://java.com/en/jre-jdk-cryptoroadmap.html#releasedChangesTable], > TLSv1 and TLSv1.1 are disabled by default as of 11.0.11+9 and 8u291b10. This > causes TLSv1.1 tests to fail. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338653#comment-17338653
]
Eric Shu commented on GEODE-8990:
-
After some debugging, I was wrong on the previous assessment that registering
interest was the cause of this flakiness. The reason is that value was modified
on the server only, but it is not entry operation that will be sent to client
cache.
serverVM.invoke("set remote session key", () -> {
final InternalCache cache = ClusterStartupRule.memberStarter.getCache();
Region region =
cache.getRegion("gemfire_modules_sessions");
region.values().forEach(session -> session.setAttribute(key,
remoteValue));
});
With the new debugging, I found out the cause for this flakiness is caused by
the memory issue, the entry put was evicted immediately. This will cause client
gets cache miss and get from server of the newer value -- causing the test to
fail.
{noformat}
[info 2021/05/03 15:26:07.093 PDT tid=0x1b] makeTombstone
stack for 15C3570A-13DD-45A0-932D-74C4CEB0958A-GF for entry
VersionedStatsLRURegionEntryHeapObjectKey@1d9493ec
(key=15C3570A-13DD-45A0-932D-74C4CEB0958A-GF;
rawValue=[id=15C3570A-13DD-45A0-932D-74C4CEB0958A-GF, isNew=false,
isValid=true, hasDelta=true, lastAccessedTime=1620080767081,
jvmOwnerId=default]; version={v3; rv3;
mbr=192.168.0.14(server-1:92400):41001;
time=1620080767088};member=192.168.0.14(server-1:92400):41001)
java.lang.Exception
at
org.apache.geode.internal.cache.entries.AbstractRegionEntry.makeTombstone(AbstractRegionEntry.java:258)
at
org.apache.geode.internal.cache.entries.AbstractRegionEntry.destroy(AbstractRegionEntry.java:880)
at
org.apache.geode.internal.cache.map.RegionMapDestroy.destroyEntry(RegionMapDestroy.java:740)
at
org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:398)
at
org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:244)
at
org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:152)
at
org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:972)
at
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6514)
at
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6488)
at
org.apache.geode.internal.cache.LocalRegion.evictDestroy(LocalRegion.java:6633)
at
org.apache.geode.internal.cache.VMLRURegionMap.evictEntry(VMLRURegionMap.java:240)
at
org.apache.geode.internal.cache.VMLRURegionMap.lruUpdateCallback(VMLRURegionMap.java:432)
at
org.apache.geode.internal.cache.map.RegionMapPut.lruUpdateCallbackIfNotCleared(RegionMapPut.java:330)
at
org.apache.geode.internal.cache.map.RegionMapPut.finishEviction(RegionMapPut.java:320)
at
org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:312)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
at
org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
at
org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2040)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5619)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5597)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5055)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1654)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1641)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:445)
at
org.apache.geode.modules.session.internal.filter.GemfireSessionManager.wrapSession(GemfireSessionManager.java:238)
at
org.apache.geode.modules.session.filter.SessionCachingFilter$RequestWrapper.getSession(SessionCachingFilter.java:179)
at
org.apache.geode.modules.session.filter.SessionCachingFilter$RequestWrapper.getSession(SessionCachingFilter.java:148)
at
org.apache.geode.modules.session.CommandServlet.doGet(CommandServlet.java:63)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
[jira] [Commented] (GEODE-9218) Geode has tests for TLSv1.1 which is disabled by default now
[ https://issues.apache.org/jira/browse/GEODE-9218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338648#comment-17338648 ] ASF subversion and git services commented on GEODE-9218: Commit c5e5024d7b4c2cd9f9f45e148701011091626143 in geode's branch refs/heads/support/1.12 from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c5e5024 ] GEODE-9218: Remove TLSv1 and TLSv1.1 from tests. (#6412) Recent versions of JDK11 and 8 have disabled TLSv1 and TLSv1.1 by default. We shouldn't be using these protocols so we shouldn't be testing them anymore either. (cherry picked from commit ee7b611b51b11693da92418c861d37ce57216298) (cherry picked from commit fdf5662d82b402ea2a95521bd910fe5de0293ce9) (cherry picked from commit ba67f4ed5b906ad99e47388b3d2c0b29c6d3751f) > Geode has tests for TLSv1.1 which is disabled by default now > > > Key: GEODE-9218 > URL: https://issues.apache.org/jira/browse/GEODE-9218 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.12.3, 1.13.3, 1.14.0, 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0, 1.15.0 > > > According to the [Oracle JRE/JDK cryptographic > roadmap|https://java.com/en/jre-jdk-cryptoroadmap.html#releasedChangesTable], > TLSv1 and TLSv1.1 are disabled by default as of 11.0.11+9 and 8u291b10. This > causes TLSv1.1 tests to fail. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9218) Geode has tests for TLSv1.1 which is disabled by default now
[ https://issues.apache.org/jira/browse/GEODE-9218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338647#comment-17338647 ] ASF subversion and git services commented on GEODE-9218: Commit ba67f4ed5b906ad99e47388b3d2c0b29c6d3751f in geode's branch refs/heads/support/1.13 from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ba67f4e ] GEODE-9218: Remove TLSv1 and TLSv1.1 from tests. (#6412) Recent versions of JDK11 and 8 have disabled TLSv1 and TLSv1.1 by default. We shouldn't be using these protocols so we shouldn't be testing them anymore either. (cherry picked from commit ee7b611b51b11693da92418c861d37ce57216298) (cherry picked from commit fdf5662d82b402ea2a95521bd910fe5de0293ce9) > Geode has tests for TLSv1.1 which is disabled by default now > > > Key: GEODE-9218 > URL: https://issues.apache.org/jira/browse/GEODE-9218 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.12.3, 1.13.3, 1.14.0, 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0, 1.15.0 > > > According to the [Oracle JRE/JDK cryptographic > roadmap|https://java.com/en/jre-jdk-cryptoroadmap.html#releasedChangesTable], > TLSv1 and TLSv1.1 are disabled by default as of 11.0.11+9 and 8u291b10. This > causes TLSv1.1 tests to fail. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9138) Add warning in server logs when data event is ignored as a duplicate
[ https://issues.apache.org/jira/browse/GEODE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338608#comment-17338608 ] ASF subversion and git services commented on GEODE-9138: Commit 6fafd3a80005b64e54ddc3cc63bf608160d25012 in geode's branch refs/heads/feature/GEODE-9138-2 from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6fafd3a ] GEODE-9138: Refactored and added tests > Add warning in server logs when data event is ignored as a duplicate > > > Key: GEODE-9138 > URL: https://issues.apache.org/jira/browse/GEODE-9138 > Project: Geode > Issue Type: Bug > Components: client/server, logging >Reporter: Diane Hardman >Assignee: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > Under certain rare conditions, a client may send or resend a data event with > an eventId that causes the server to interpret it as a duplicate event and > discard it. > It is currently impossible to trace when this happens without extra logging > added. > From Barry: > No, if the server thinks it has seen the event, it silently eats it. See > DistributedEventTracker.hasSeenEvent. It has a trace log message but thats it. > The log message that tracks this behavior in the server needs to be added > permanently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9233) Implement ZADD and ZSCORE
[ https://issues.apache.org/jira/browse/GEODE-9233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Ingles updated GEODE-9233: -- Description: Initial implementation of the Redis ZADD and ZSCORE commands. (was: Inititial implementation of the Redis ZADD and ZSCORE commands.) > Implement ZADD and ZSCORE > - > > Key: GEODE-9233 > URL: https://issues.apache.org/jira/browse/GEODE-9233 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Priority: Major > > Initial implementation of the Redis ZADD and ZSCORE commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9233) Implement ZADD and ZSCORE
Ray Ingles created GEODE-9233: - Summary: Implement ZADD and ZSCORE Key: GEODE-9233 URL: https://issues.apache.org/jira/browse/GEODE-9233 Project: Geode Issue Type: Improvement Components: redis Affects Versions: 1.15.0 Reporter: Ray Ingles Inititial implementation of the Redis ZADD and ZSCORE commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9138) Add warning in server logs when data event is ignored as a duplicate
[ https://issues.apache.org/jira/browse/GEODE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338596#comment-17338596 ] ASF subversion and git services commented on GEODE-9138: Commit bc8c4426a91c0685c81f9b6e2c00390f8f54b5a0 in geode's branch refs/heads/develop from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bc8c442 ] GEODE-9138: Ignore failing test in windows > Add warning in server logs when data event is ignored as a duplicate > > > Key: GEODE-9138 > URL: https://issues.apache.org/jira/browse/GEODE-9138 > Project: Geode > Issue Type: Bug > Components: client/server, logging >Reporter: Diane Hardman >Assignee: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > Under certain rare conditions, a client may send or resend a data event with > an eventId that causes the server to interpret it as a duplicate event and > discard it. > It is currently impossible to trace when this happens without extra logging > added. > From Barry: > No, if the server thinks it has seen the event, it silently eats it. See > DistributedEventTracker.hasSeenEvent. It has a trace log message but thats it. > The log message that tracks this behavior in the server needs to be added > permanently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9190) Cleanup of Stats Code Warnings
[ https://issues.apache.org/jira/browse/GEODE-9190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson resolved GEODE-9190. Fix Version/s: 1.15.0 Resolution: Fixed > Cleanup of Stats Code Warnings > -- > > Key: GEODE-9190 > URL: https://issues.apache.org/jira/browse/GEODE-9190 > Project: Geode > Issue Type: Improvement > Components: statistics >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > There are ton of warnings in the stats files for various reasons. I went > through and cleaned up a bunch of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9232) Serialization state differences between primary and secondary impact tests
Ray Ingles created GEODE-9232: - Summary: Serialization state differences between primary and secondary impact tests Key: GEODE-9232 URL: https://issues.apache.org/jira/browse/GEODE-9232 Project: Geode Issue Type: Bug Components: redis Reporter: Ray Ingles When confirming the implementation of the 'Sizeable' interface for Radish (GEODE-9136), testing proved difficult because the size of data could be different between the primary and secondary. On the primary, the data would be stored deserialized, but on the secondary, it could be stored serialized, even after a delta was applied. Some way of either forcing deserialization, or else validating size while serialized, needs to be found. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8925) Migrate old integration test testThinClientPRSingleHop to new test framework
[ https://issues.apache.org/jira/browse/GEODE-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-8925. --- > Migrate old integration test testThinClientPRSingleHop to new test framework > > > Key: GEODE-8925 > URL: https://issues.apache.org/jira/browse/GEODE-8925 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The following singleHop tests are marked Flaky. This ticket is to port these > to the new framework. > * testThinClientPRSingleHop > * testThinClientPutAllPRSingleHop -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8925) Migrate old integration test testThinClientPRSingleHop to new test framework
[ https://issues.apache.org/jira/browse/GEODE-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-8925. - Resolution: Fixed > Migrate old integration test testThinClientPRSingleHop to new test framework > > > Key: GEODE-8925 > URL: https://issues.apache.org/jira/browse/GEODE-8925 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The following singleHop tests are marked Flaky. This ticket is to port these > to the new framework. > * testThinClientPRSingleHop > * testThinClientPutAllPRSingleHop -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9198) Keystore/truststore file watcher does not follow symbolic links
[ https://issues.apache.org/jira/browse/GEODE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338527#comment-17338527 ] ASF subversion and git services commented on GEODE-9198: Commit 7e1ed12414c5eb401ddb4cc9b4b8a6a3d1ae4dd5 in geode's branch refs/heads/develop from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e1ed12 ] GEODE-9198: Key/trust store watcher follows symlinks (#6380) GEODE-9017 introduced a file watching key/trust manager to automatically reload the key and trust store upon change. However, in the situation where the key/trust store files are represented by a symbolic links, the manager would not reload the store correctly. This commit changes the watcher to follow symbolic links. > Keystore/truststore file watcher does not follow symbolic links > --- > > Key: GEODE-9198 > URL: https://issues.apache.org/jira/browse/GEODE-9198 > Project: Geode > Issue Type: Bug >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > GEODE-9017 introduced a file watching key/trust manager to automatically > reload the key and trust store upon change. However, the file watcher was > configured to not follow symbolic links. Some environments such as Kubernetes > use symbolic links to mount files inside a container file system. In cases > like this (where the key and trust store are represented using symbolic > links) the file watcher should follow these links and reload the key and > trust store when the underlying target file changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9017) Reload key store and trust store upon change
[ https://issues.apache.org/jira/browse/GEODE-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338528#comment-17338528 ] ASF subversion and git services commented on GEODE-9017: Commit 7e1ed12414c5eb401ddb4cc9b4b8a6a3d1ae4dd5 in geode's branch refs/heads/develop from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e1ed12 ] GEODE-9198: Key/trust store watcher follows symlinks (#6380) GEODE-9017 introduced a file watching key/trust manager to automatically reload the key and trust store upon change. However, in the situation where the key/trust store files are represented by a symbolic links, the manager would not reload the store correctly. This commit changes the watcher to follow symbolic links. > Reload key store and trust store upon change > > > Key: GEODE-9017 > URL: https://issues.apache.org/jira/browse/GEODE-9017 > Project: Geode > Issue Type: New Feature >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > [Link to > RFC|https://cwiki.apache.org/confluence/display/GEODE/Make+key+and+trust+stores+reload+automatically+upon+change] > (The below text is copied from the RFC document.) > h3. Problem > Currently, in order to rotate certificates each member of the cluster needs > to be restarted to load new certs and trust. It would be preferable if > certificates can be rotated without having to restart members. > h3. Solution > When starting up a cluster member we currently read the TLS configuration > which, when TLS is enabled has key and trust store files defined. In case > those files are defined they are read, and the information inside them is > loaded into the key and trust manager objects that are loaded into the > SSLContext. > This solution will introduce wrapper objects for the key and trust managers > and file/directory watcher(s) that can detect changes to the key and trust > store files. When key and trust store files are changed this will trigger a > reload into key and trust managers and through the wrapper objects these new > key and trust managers will be injected into the SSLContext so that the > context can start using the new key and trust managers in process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9198) Keystore/truststore file watcher does not follow symbolic links
[ https://issues.apache.org/jira/browse/GEODE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-9198. -- Fix Version/s: 1.15.0 Resolution: Fixed > Keystore/truststore file watcher does not follow symbolic links > --- > > Key: GEODE-9198 > URL: https://issues.apache.org/jira/browse/GEODE-9198 > Project: Geode > Issue Type: Bug >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > GEODE-9017 introduced a file watching key/trust manager to automatically > reload the key and trust store upon change. However, the file watcher was > configured to not follow symbolic links. Some environments such as Kubernetes > use symbolic links to mount files inside a container file system. In cases > like this (where the key and trust store are represented using symbolic > links) the file watcher should follow these links and reload the key and > trust store when the underlying target file changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9204) A not serializable exception can cause a ServerConnection thread to get stuck waiting for a reply from another member
[
https://issues.apache.org/jira/browse/GEODE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-9204:
---
Assignee: Kamilla Aslami (was: Bruce J Schuchardt)
> A not serializable exception can cause a ServerConnection thread to get stuck
> waiting for a reply from another member
> -
>
> Key: GEODE-9204
> URL: https://issues.apache.org/jira/browse/GEODE-9204
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
>
> A test case that reproduces it is:
> - a client get request is received in one server and sent to another server
> - the other server uses a CacheLoader to load the value
> - the CacheLoader throws an exception containing a non-serializable object
> - the reply attempts to serialize that exception but fails with
> NotSerializableException
> - the original server's ServerConnection thread gets stuck waiting for a
> reply that will never come
> Here is a stack trace showing the NotSerializableException:
> {noformat}
> [severe 2018/03/20 14:30:27.793 PDT elgreco(85544):30177 unshared ordered uid=14 dom #1 port=53923>
> tid=0x5c] Uncaught exception processing partitioned.GetMessage(prid=2 (name
> = "/data") processorId=0; posDup=false; key=0; callback arg=null;
> context=identity(elgreco(client:85552:loner):53907:fce35145:client,connection=2)
> org.apache.geode.InternalGemFireException: java.io.NotSerializableException:
> java.lang.Object
> at
> org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:76)
> at
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:109)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:392)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:449)
> at
> org.apache.geode.distributed.internal.DistributionManager.scheduleIncomingMessage(DistributionManager.java:3872)
> at
> org.apache.geode.distributed.internal.DistributionManager.handleIncomingDMsg(DistributionManager.java:3496)
> at
> org.apache.geode.distributed.internal.DistributionManager$MyListener.messageReceived(DistributionManager.java:4693)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.processMessage(JGroupMembershipManager.java:2128)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.handleOrDeferMessage(JGroupMembershipManager.java:2037)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager$MyDCReceiver.messageReceived(JGroupMembershipManager.java:647)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:804)
> at
> org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:835)
> at
> org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3932)
> at
> org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3515)
> at
> org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1827)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1702)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.NotSerializableException: java.lang.Object
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
> at java.lang.Throwable.writeObject(Throwable.java:985)
> 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
>
[jira] [Updated] (GEODE-9103) CI Failure: PutAllClientServerDistributedTest.testPutAllReturnsExceptions FAILED
[
https://issues.apache.org/jira/browse/GEODE-9103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9103:
-
Labels: GeodeOperationAPI (was: )
> CI Failure: PutAllClientServerDistributedTest.testPutAllReturnsExceptions
> FAILED
>
>
> Key: GEODE-9103
> URL: https://issues.apache.org/jira/browse/GEODE-9103
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest >
> testPutAllReturnsExceptions FAILED
> 17:13:44org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$613/835527630.run
> in VM 2 running on Host de2767658753 with 4 VMs
> 17:13:44at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> 17:13:44at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> 17:13:44at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPutAllReturnsExceptions(PutAllClientServerDistributedTest.java:1956)
> 17:13:44
> 17:13:44Caused by:
> 17:13:44java.lang.AssertionError:
> 17:13:44Expecting actual throwable to be an instance of:
> 17:13:44 org.apache.geode.cache.client.ServerOperationException
> 17:13:44but was:
> 17:13:44 org.apache.geode.cache.client.ServerConnectivityException:
> Pool unexpected closed socket on server connection=Pooled Connection to
> de2767658753:36547,172.17.0.10(245):41001: Connection[DESTROYED]).
> Server unreachable: could not connect after 1 attempts
> 17:13:44 at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:665)
> 17:13:44 at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:507)
> 17:13:44 at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:157)
> 17:13:44 ...(35 remaining lines not displayed - this can be
> changed with Assertions.setMaxStackTraceElementsDisplayed)
> 17:13:44at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.lambda$testPutAllReturnsExceptions$bb17a952$6(PutAllClientServerDistributedTest.java:1961)
> 17:16 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9195) Remove redundant local locking from PartitionedRegionClear
[
https://issues.apache.org/jira/browse/GEODE-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-9195.
--
Resolution: Fixed
Merged to feature/GEODE-7665
> Remove redundant local locking from PartitionedRegionClear
> --
>
> Key: GEODE-9195
> URL: https://issues.apache.org/jira/browse/GEODE-9195
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear unconditionally acquires a global lock and also acquires local locks
> on all buckets before doing clear.
> Expected behavior:
> Now that PR clear acquires a global lock, it no longer needs to acquire local
> locks on all buckets before doing clear.
> Solution:
> Remove the logic taking lock in individual nodes in:
> {noformat}
> DistributedRegion.obtainWriteLocksForClear()
> {noformat}
> Remove:
> {noformat}
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338453#comment-17338453
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#181.4|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/181.4]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0182/test-results/distributedTest/1619840960/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0182/test-artifacts/1619840960/distributedtestfiles-OpenJDK8-1.15.0-build.0182.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338450#comment-17338450
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#200|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/200]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0189/test-results/distributedTest/1619854907/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0189/test-artifacts/1619854907/distributedtestfiles-OpenJDK8-1.15.0-build.0189.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9138) Add warning in server logs when data event is ignored as a duplicate
[ https://issues.apache.org/jira/browse/GEODE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338449#comment-17338449 ] ASF subversion and git services commented on GEODE-9138: Commit 4c8c8e6cdf260fdbbe48b1fddf9c2adc97209a3b in geode's branch refs/heads/feature/GEODE-9138-ignore-test from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c8c8e6 ] GEODE-9138: Force CI to re-run > Add warning in server logs when data event is ignored as a duplicate > > > Key: GEODE-9138 > URL: https://issues.apache.org/jira/browse/GEODE-9138 > Project: Geode > Issue Type: Bug > Components: client/server, logging >Reporter: Diane Hardman >Assignee: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > Under certain rare conditions, a client may send or resend a data event with > an eventId that causes the server to interpret it as a duplicate event and > discard it. > It is currently impossible to trace when this happens without extra logging > added. > From Barry: > No, if the server thinks it has seen the event, it silently eats it. See > DistributedEventTracker.hasSeenEvent. It has a trace log message but thats it. > The log message that tracks this behavior in the server needs to be added > permanently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7455) CI Failure: AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean Failed
[
https://issues.apache.org/jira/browse/GEODE-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338448#comment-17338448
]
Geode Integration commented on GEODE-7455:
--
Seen in [DistributedTestOpenJDK8
#186|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/186]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0188/test-results/distributedTest/1619846875/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0188/test-artifacts/1619846875/distributedtestfiles-OpenJDK8-1.15.0-build.0188.tgz].
> CI Failure:
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> Failed
> --
>
> Key: GEODE-7455
> URL: https://issues.apache.org/jira/browse/GEODE-7455
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: flaky
>
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> failed in DistributedTestOpenJDK11 below are the relevant details.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1280]
>
> {noformat}
> 13:30:08
> org.apache.geode.management.AEQManagementDUnitTest >
> testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean FAILED
> 13:30:08
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.AEQManagementDUnitTest$$Lambda$200/0x0008407dec40.run
> in VM 0 running on Host 0e592392f6db with 4 VMs
> 13:30:08
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> 13:30:08
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> 13:30:08
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 13:30:08
> at
> org.apache.geode.management.AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean(AEQManagementDUnitTest.java:245)
> 13:30:0813:30:08
> Caused by:
> 13:30:08
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 13:30:08
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 13:30:08
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 13:30:08
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 13:30:08
> at
> org.apache.geode.management.AEQManagementDUnitTest.lambda$testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean$d4d42c35$1(AEQManagementDUnitTest.java:250)
> 14:10:3714:10:37
> 793 tests completed, 1 failed, 61 skipped {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-results/distributedTest/1573687903/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-artifacts/1573687903/distributedtestfiles-OpenJDK11-1.12.0-SNAPSHOT.0013.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7455) CI Failure: AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean Failed
[
https://issues.apache.org/jira/browse/GEODE-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338447#comment-17338447
]
Geode Integration commented on GEODE-7455:
--
Seen in [DistributedTestOpenJDK8
#200|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/200]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0189/test-results/distributedTest/1619854907/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0189/test-artifacts/1619854907/distributedtestfiles-OpenJDK8-1.15.0-build.0189.tgz].
> CI Failure:
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> Failed
> --
>
> Key: GEODE-7455
> URL: https://issues.apache.org/jira/browse/GEODE-7455
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: flaky
>
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> failed in DistributedTestOpenJDK11 below are the relevant details.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1280]
>
> {noformat}
> 13:30:08
> org.apache.geode.management.AEQManagementDUnitTest >
> testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean FAILED
> 13:30:08
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.AEQManagementDUnitTest$$Lambda$200/0x0008407dec40.run
> in VM 0 running on Host 0e592392f6db with 4 VMs
> 13:30:08
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> 13:30:08
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> 13:30:08
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 13:30:08
> at
> org.apache.geode.management.AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean(AEQManagementDUnitTest.java:245)
> 13:30:0813:30:08
> Caused by:
> 13:30:08
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 13:30:08
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 13:30:08
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 13:30:08
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 13:30:08
> at
> org.apache.geode.management.AEQManagementDUnitTest.lambda$testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean$d4d42c35$1(AEQManagementDUnitTest.java:250)
> 14:10:3714:10:37
> 793 tests completed, 1 failed, 61 skipped {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-results/distributedTest/1573687903/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-artifacts/1573687903/distributedtestfiles-OpenJDK11-1.12.0-SNAPSHOT.0013.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7455) CI Failure: AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean Failed
[
https://issues.apache.org/jira/browse/GEODE-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338444#comment-17338444
]
Geode Integration commented on GEODE-7455:
--
Seen in [DistributedTestOpenJDK8
#205|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/205]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0185/test-results/distributedTest/1619855328/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0185/test-artifacts/1619855328/distributedtestfiles-OpenJDK8-1.15.0-build.0185.tgz].
> CI Failure:
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> Failed
> --
>
> Key: GEODE-7455
> URL: https://issues.apache.org/jira/browse/GEODE-7455
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: flaky
>
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> failed in DistributedTestOpenJDK11 below are the relevant details.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1280]
>
> {noformat}
> 13:30:08
> org.apache.geode.management.AEQManagementDUnitTest >
> testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean FAILED
> 13:30:08
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.AEQManagementDUnitTest$$Lambda$200/0x0008407dec40.run
> in VM 0 running on Host 0e592392f6db with 4 VMs
> 13:30:08
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> 13:30:08
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> 13:30:08
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 13:30:08
> at
> org.apache.geode.management.AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean(AEQManagementDUnitTest.java:245)
> 13:30:0813:30:08
> Caused by:
> 13:30:08
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 13:30:08
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 13:30:08
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 13:30:08
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 13:30:08
> at
> org.apache.geode.management.AEQManagementDUnitTest.lambda$testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean$d4d42c35$1(AEQManagementDUnitTest.java:250)
> 14:10:3714:10:37
> 793 tests completed, 1 failed, 61 skipped {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-results/distributedTest/1573687903/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-artifacts/1573687903/distributedtestfiles-OpenJDK11-1.12.0-SNAPSHOT.0013.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8405) Native Client asks for metadata for replicated region, causes server exception
[
https://issues.apache.org/jira/browse/GEODE-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338394#comment-17338394
]
ASF GitHub Bot commented on GEODE-8405:
---
pivotal-jbarrett commented on a change in pull request #800:
URL: https://github.com/apache/geode-native/pull/800#discussion_r625129556
##
File path: cppcache/src/ClientMetadataService.cpp
##
@@ -121,6 +121,14 @@ void ClientMetadataService::getClientPRMetadata(const
char* regionFullPath) {
if (err == GF_NOERR &&
reply.getMessageType() ==
TcrMessage::RESPONSE_CLIENT_PARTITION_ATTRIBUTES) {
+ // By convention, server returns -1 bucket count to indicate replicated
+ // region
+ if (reply.getNumBuckets() == -1) {
+LOGDEBUG(
Review comment:
I am not sure this is worth logging. Knowing this information is
unlikely to help us debug anything.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Native Client asks for metadata for replicated region, causes server exception
> --
>
> Key: GEODE-8405
> URL: https://issues.apache.org/jira/browse/GEODE-8405
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> For some reason, Geode Native is not checking region attributes on the server
> prior to issuing a GET_CLIENT_PR_METADATA message. It does, in fact, get the
> region attributes from the server, as you can see from this message dump:
> {code:java}
> {
> "Timestamp": "2020-08-05 15:37:42.595294",
> "Connection": "0x7fb1f89042d0",
> "Direction": "--->",
> "Type": "GET_CLIENT_PARTITION_ATTRIBUTES",
> "Length": 22,
> "Parts": 1,
> "TransactionId": -1,
> "SecurityFlag": 0,
> "RegionPart": {
> "Size": 17,
> "IsObject": 0,
> "Name": "/example_userinfo"
> }
> }
> ,{
> "Timestamp": "15:37:42.595590",
> "Connection": "0",
> "Direction": "<---",
> "Type": "RESPONSE_CLIENT_PARTITION_ATTRIBUTES",
> "Length": 35,
> "Parts": 2,
> "TransactionId": -1,
> "SecurityFlag": 0,
> "BucketCount": {
> "Size": 5,
> "IsObject": 1,
> "Data":{
> "DSCode": "CacheableInt32",
> "Value": -1
> }
> },
> "ColocatedWith": {
> "Size": 20,
> "IsObject": 1,
> "Data":{
> "DSCode": "CacheableASCIIString",
> "StringLength": 17,
> "Value": "/example_userinfo"
> }
> }
> }
> {code}
>
> The critical value here is `BucketCount` in the
> `RESPONSE_CLIENT_PARTITION_ATTRIBUTES` message. If this value is -1, the
> region is replicated rather than partitioned, and we should not be querying
> for PR metadata.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9138) Add warning in server logs when data event is ignored as a duplicate
[ https://issues.apache.org/jira/browse/GEODE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338355#comment-17338355 ] ASF subversion and git services commented on GEODE-9138: Commit 749ba4f600ebac143c7a23ae11c876734fba1679 in geode's branch refs/heads/feature/GEODE-9138-ignore-test from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=749ba4f ] GEODE-9138: Ignore failing test > Add warning in server logs when data event is ignored as a duplicate > > > Key: GEODE-9138 > URL: https://issues.apache.org/jira/browse/GEODE-9138 > Project: Geode > Issue Type: Bug > Components: client/server, logging >Reporter: Diane Hardman >Assignee: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > Under certain rare conditions, a client may send or resend a data event with > an eventId that causes the server to interpret it as a duplicate event and > discard it. > It is currently impossible to trace when this happens without extra logging > added. > From Barry: > No, if the server thinks it has seen the event, it silently eats it. See > DistributedEventTracker.hasSeenEvent. It has a trace log message but thats it. > The log message that tracks this behavior in the server needs to be added > permanently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9173) Bump Swagger2 to newer version
[ https://issues.apache.org/jira/browse/GEODE-9173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-9173: - Assignee: Mario Kevo > Bump Swagger2 to newer version > -- > > Key: GEODE-9173 > URL: https://issues.apache.org/jira/browse/GEODE-9173 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Udo Kohlmeyer >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9173) Bump Swagger2 to newer version
[ https://issues.apache.org/jira/browse/GEODE-9173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9173: -- Labels: pull-request-available (was: ) > Bump Swagger2 to newer version > -- > > Key: GEODE-9173 > URL: https://issues.apache.org/jira/browse/GEODE-9173 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
