[jira] [Resolved] (GEODE-10295) ambiguous toArray call
[ https://issues.apache.org/jira/browse/GEODE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10295. -- Resolution: Won't Fix only ambiguous when compiled with JDK11, which is not supported anyway > ambiguous toArray call > -- > > Key: GEODE-10295 > URL: https://issues.apache.org/jira/browse/GEODE-10295 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0, 1.16.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > geode-core/src/main/java/org/apache/geode/internal/cache/EntriesSet.java:245: > error: reference to toArray is ambiguous > return toArray(null); -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[ https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534670#comment-17534670 ] ASF GitHub Bot commented on GEODE-10218: lgtm-com[bot] commented on PR #954: URL: https://github.com/apache/geode-native/pull/954#issuecomment-1123172546 This pull request **introduces 1 alert** when merging 927e176d7433e029d7cae2ca7edd64d658f0ceac into 4d0578a829ee4d967ec4358133e4a8c3563f1310 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-f563aca93e0096a331c3a653777f131820e36a0d) **new alerts:** * 1 for Useless assignment to local variable > Launch Cluster with Attachability Flag > -- > > Key: GEODE-10218 > URL: https://issues.apache.org/jira/browse/GEODE-10218 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Minor > Labels: pull-request-available > > To assist with protocol analysis it is very helpful to be able to step > through the server code in the Intellij debugger while running native client > test code. However, to be allowed to set breakpoints in the server code, the > server must be started with the special flag below: > > --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT > This ticket is to add support for the above flag in the native client test > frameworks. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534649#comment-17534649
]
Jacob Barrett commented on GEODE-10297:
---
When creating an {{SSLContext}} in {{SSLUtil}} we use the {{ssl-protocols}}
list to for the {{SSLContext}} instance. It loops over the list and returns the
first request that doesn't result in an exception. In the example case
{{TLSv1.2}} context is found first, which supports {{TLSv1.2}} as its newest
protocol.
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, needsTriage
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10297:
--
Affects Version/s: 1.14.4
1.13.8
1.12.9
1.15.0
1.16.0
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10297:
--
Labels: blocks-1.15.0 needsTriage (was: needsTriage)
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, needsTriage
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10297:
--
Labels: needsTriage (was: )
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
Jacob Barrett created GEODE-10297:
-
Summary: SSL protocol ordering can result in loss of newer
protocol support.
Key: GEODE-10297
URL: https://issues.apache.org/jira/browse/GEODE-10297
Project: Geode
Issue Type: Bug
Components: core
Reporter: Jacob Barrett
If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
the {{SSLContext}} used will support at most that weaker protocol.
For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the {{TLSv1.2}}
{{SSLContext}}, which will not support, and silently ignore, the {{TLSv1.3}}
configuration. The effective enabled protocols list will be {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10296) Parser error in HDR histogram log can result in terminate of JVM
[ https://issues.apache.org/jira/browse/GEODE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett reassigned GEODE-10296: - Assignee: Jacob Barrett > Parser error in HDR histogram log can result in terminate of JVM > > > Key: GEODE-10296 > URL: https://issues.apache.org/jira/browse/GEODE-10296 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > The HDR histogram parser exits the JVM on parsing errors. This results in > benchmarks failing even if the parser error is later recoverable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10296) Parser error in HDR histogram log can result in terminate of JVM
[ https://issues.apache.org/jira/browse/GEODE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534647#comment-17534647 ] ASF GitHub Bot commented on GEODE-10296: pivotal-jbarrett opened a new pull request, #168: URL: https://github.com/apache/geode-benchmarks/pull/168 Configure HistogramLogProcessor to throw exceptions rather than exit. > Parser error in HDR histogram log can result in terminate of JVM > > > Key: GEODE-10296 > URL: https://issues.apache.org/jira/browse/GEODE-10296 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage > > The HDR histogram parser exits the JVM on parsing errors. This results in > benchmarks failing even if the parser error is later recoverable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10296) Parser error in HDR histogram log can result in terminate of JVM
[ https://issues.apache.org/jira/browse/GEODE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10296: --- Labels: needsTriage pull-request-available (was: needsTriage) > Parser error in HDR histogram log can result in terminate of JVM > > > Key: GEODE-10296 > URL: https://issues.apache.org/jira/browse/GEODE-10296 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > The HDR histogram parser exits the JVM on parsing errors. This results in > benchmarks failing even if the parser error is later recoverable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10296) Parser error in HDR histogram log can result in terminate of JVM
[ https://issues.apache.org/jira/browse/GEODE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10296: -- Labels: needsTriage (was: ) > Parser error in HDR histogram log can result in terminate of JVM > > > Key: GEODE-10296 > URL: https://issues.apache.org/jira/browse/GEODE-10296 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage > > The HDR histogram parser exits the JVM on parsing errors. This results in > benchmarks failing even if the parser error is later recoverable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10296) Parser error in HDR histogram log can result in terminate of JVM
Jacob Barrett created GEODE-10296: - Summary: Parser error in HDR histogram log can result in terminate of JVM Key: GEODE-10296 URL: https://issues.apache.org/jira/browse/GEODE-10296 Project: Geode Issue Type: Bug Components: benchmarks Reporter: Jacob Barrett The HDR histogram parser exits the JVM on parsing errors. This results in benchmarks failing even if the parser error is later recoverable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[ https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534626#comment-17534626 ] ASF GitHub Bot commented on GEODE-10218: lgtm-com[bot] commented on PR #954: URL: https://github.com/apache/geode-native/pull/954#issuecomment-1123054711 This pull request **introduces 1 alert** when merging 4329b35950257a683e7654abce5ef4f91cb3c609 into 4d0578a829ee4d967ec4358133e4a8c3563f1310 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-2cc182192ac72cdaa2e11c915a8d06927a438ed1) **new alerts:** * 1 for Useless assignment to local variable > Launch Cluster with Attachability Flag > -- > > Key: GEODE-10218 > URL: https://issues.apache.org/jira/browse/GEODE-10218 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Minor > Labels: pull-request-available > > To assist with protocol analysis it is very helpful to be able to step > through the server code in the Intellij debugger while running native client > test code. However, to be allowed to set breakpoints in the server code, the > server must be started with the special flag below: > > --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT > This ticket is to add support for the above flag in the native client test > frameworks. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10289) Add an argument file that opens all JDK packages to all unnamed modules
[
https://issues.apache.org/jira/browse/GEODE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534617#comment-17534617
]
ASF subversion and git services commented on GEODE-10289:
-
Commit 729680cea207b57120db615f442dd3a0b4d58087 in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=729680cea2 ]
GEODE-10289: Argument file for JDK 17 (#7673)
* GEODE-10289: Argument file for JDK 17
The argument file was generated on Linux using OpenJDK 17.0.2
* Add arg file to assembly_content.txt
> Add an argument file that opens all JDK packages to all unnamed modules
> ---
>
> Key: GEODE-10289
> URL: https://issues.apache.org/jira/browse/GEODE-10289
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
>
> Certain Geode functionality requires user-defined objects to be accessible
> for reflection. It can be difficult for users to identify non-opened JDK
> packages that are included in their objects.
> Add an argument file that opens all JDK packages to all unnamed modules.
> Adding this argument file when launching a client, locator, or server on JDK
> 17 essentially mimics the {{--illegal-access=permit}} option from JDK 11 (at
> least for JDK packages).
> The supplied argument file will open all packages that come with the Linux
> version of OpenJDK.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10286) cache close in response to a forced disconnect with persistent regions may skip some cleanup
[
https://issues.apache.org/jira/browse/GEODE-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10286:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> cache close in response to a forced disconnect with persistent regions may
> skip some cleanup
> -
>
> Key: GEODE-10286
> URL: https://issues.apache.org/jira/browse/GEODE-10286
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> During a cache close, persistent regions may not cleanup as much as they
> should. This is because when the PersistentAdvisor is closed, CancelException
> is not handled causing other parts of the close to be skipped. I think the
> place to handle it is:
> DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564). Here
> is an exception showing what it looks like when this happens:
> {noformat}
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on rs-RunItNow-ZH1504a1i3xlarge-hydra-client-10(dataStor
> egemfire2_host1_421:421):41004 started at Wed Mar 23 17:11:48 PDT
> 2022: Member isn't responding to heartbeat requests, caused by org.apac
> he.geode.ForcedDisconnectException: Member isn't responding to heartbeat
> requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:289
> 3)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.ClusterElderManager.getElderId(ClusterElderManager.java:76)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.getElderId(ClusterDistributionManager.java:2085)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getElderId(DLockService.java:254)
> at
> org.apache.geode.distributed.internal.locks.DLockService.notLockGrantorId(DLockService.java:824)
> at
> org.apache.geode.distributed.internal.locks.DLockService.unlock(DLockService.java:1807)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.releaseTieLock(PersistenceAdvisorImpl.java:1181)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.close(PersistenceAdvisorImpl.java:1158)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564)
> at
> org.apache.geode.internal.cache.DistributedRegion.postDestroyRegion(DistributedRegion.java:2657)
> at
> org.apache.geode.internal.cache.LocalRegion.recursiveDestroyRegion(LocalRegion.java:2732)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6241)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1834)
> at
> org.apache.geode.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7320)
> at
> org.apache.geode.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2691)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2308)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2154)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1538)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2545)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2408)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1254)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2329)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager
[jira] [Assigned] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jianxia Chen reassigned GEODE-10287: Assignee: Jianxia Chen (was: Jinmei Liao) > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jianxia Chen >Priority: Major > Labels: needsTriage > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-10287: --- Assignee: Jinmei Liao > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10295) ambiguous toArray call
[ https://issues.apache.org/jira/browse/GEODE-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10295: --- Labels: pull-request-available (was: ) > ambiguous toArray call > -- > > Key: GEODE-10295 > URL: https://issues.apache.org/jira/browse/GEODE-10295 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0, 1.16.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > geode-core/src/main/java/org/apache/geode/internal/cache/EntriesSet.java:245: > error: reference to toArray is ambiguous > return toArray(null); -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[ https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534604#comment-17534604 ] ASF GitHub Bot commented on GEODE-10218: mmartell commented on code in PR #954: URL: https://github.com/apache/geode-native/pull/954#discussion_r869734411 ## cppcache/integration/framework/Cluster.h: ## @@ -124,6 +124,7 @@ using Password = NamedType; using CacheXMLFiles = NamedType, struct CacheXMLFilesParameter>; using UseIpv6 = NamedType; +using UseDebugAgent = NamedType; Review Comment: Done > Launch Cluster with Attachability Flag > -- > > Key: GEODE-10218 > URL: https://issues.apache.org/jira/browse/GEODE-10218 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Minor > Labels: pull-request-available > > To assist with protocol analysis it is very helpful to be able to step > through the server code in the Intellij debugger while running native client > test code. However, to be allowed to set breakpoints in the server code, the > server must be started with the special flag below: > > --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT > This ticket is to add support for the above flag in the native client test > frameworks. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[
https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534603#comment-17534603
]
ASF GitHub Bot commented on GEODE-10218:
mmartell commented on code in PR #954:
URL: https://github.com/apache/geode-native/pull/954#discussion_r869733477
##
cppcache/integration/framework/Cluster.h:
##
@@ -141,6 +142,9 @@ class Cluster {
Cluster(InitialLocators initialLocators, InitialServers initialServers,
UseIpv6 useIpv6 = UseIpv6{false});
+ Cluster(InitialLocators initialLocators, InitialServers initialServers,
+ UseDebugAgent allowAttach);
Review Comment:
Done
> Launch Cluster with Attachability Flag
> --
>
> Key: GEODE-10218
> URL: https://issues.apache.org/jira/browse/GEODE-10218
> Project: Geode
> Issue Type: Test
> Components: native client
>Reporter: Michael Martell
>Assignee: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> To assist with protocol analysis it is very helpful to be able to step
> through the server code in the Intellij debugger while running native client
> test code. However, to be allowed to set breakpoints in the server code, the
> server must be started with the special flag below:
>
> --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT
> This ticket is to add support for the above flag in the native client test
> frameworks.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[
https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534602#comment-17534602
]
ASF GitHub Bot commented on GEODE-10218:
mmartell commented on code in PR #954:
URL: https://github.com/apache/geode-native/pull/954#discussion_r869732762
##
clicache/integration-test2/GfshTest.cs:
##
@@ -77,13 +77,16 @@ public void StartLocatorStringsTest()
.withSslKeyStore("some/path/keystore.jks")
.withSslKeyStorePassword("password1")
.withSslTrustStore("some/path/truststore.jks")
-.withSslTrustStorePassword("password2");
+.withSslTrustStorePassword("password2")
+.withDebugAgent(true, "address");
s = locator.ToString();
+var withAttachPortRemoved = s.Substring(0, s.LastIndexOf(":",
s.Length-1, 6));
Review Comment:
Good catch. No longer using attach nomenclature.
> Launch Cluster with Attachability Flag
> --
>
> Key: GEODE-10218
> URL: https://issues.apache.org/jira/browse/GEODE-10218
> Project: Geode
> Issue Type: Test
> Components: native client
>Reporter: Michael Martell
>Assignee: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> To assist with protocol analysis it is very helpful to be able to step
> through the server code in the Intellij debugger while running native client
> test code. However, to be allowed to set breakpoints in the server code, the
> server must be started with the special flag below:
>
> --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT
> This ticket is to add support for the above flag in the native client test
> frameworks.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10295) ambiguous toArray call
Owen Nichols created GEODE-10295: Summary: ambiguous toArray call Key: GEODE-10295 URL: https://issues.apache.org/jira/browse/GEODE-10295 Project: Geode Issue Type: Improvement Components: core Affects Versions: 1.15.0, 1.16.0 Reporter: Owen Nichols geode-core/src/main/java/org/apache/geode/internal/cache/EntriesSet.java:245: error: reference to toArray is ambiguous return toArray(null); -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9906) Unable to reconnect a node after SO patching "15 seconds have elapsed while waiting for replies"
[ https://issues.apache.org/jira/browse/GEODE-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534595#comment-17534595 ] Hale Bales commented on GEODE-9906: --- Hi [~mb1977], thank you for raising this issue. Given that it is on such an old version of Geode, I am going to close this ticket. If you can, please try to reproduce this issue on develop or the most recent release and reopen the issue if it is still a problem. Please reach out on the dev list if you have issues using the most recent version. Thanks! > Unable to reconnect a node after SO patching "15 seconds have elapsed while > waiting for replies" > > > Key: GEODE-9906 > URL: https://issues.apache.org/jira/browse/GEODE-9906 > Project: Geode > Issue Type: Bug >Reporter: Marco Baldessari >Priority: Major > > I have a cluster situation consisting of 4 total nodes, 3 servers and 1 > management node, working properly. > At the beginning of the month we planned to patch the OS and we started from > the first server node with this procedure: > - Stop service > - S.O. patching > - Server restart > - Start service > The service of the first patched node named "serverA" fails to restart with > this error: > Log entries cluster join: > serverA: > | INFO | region-dm-12 | ache.geode.internal.tcp.Connection | > --> Connection: shared=true ordered=false failed to connect to peer > 10.237.110.195( Server serverB:9993):1024 because: > java.net.ConnectException: Connection timed out (Connection timed out) > | WARN | region-dm-12 | ache.geode.internal.tcp.Connection | > --> Connection: Attempting reconnect to peer 10.237.110.195( Server > serverB:9993):1024 > > ServerMgmt: > | WARN | pool-3-thread-1 | tributed.internal.ReplyProcessor21 > | --> 15 seconds have elapsed while waiting for replies: > from [10.237.110.194( Server serverA:632):1024]> on 10.237.110.225( > Management:6033):1024 whose current membership list is: > [[10.237.110.196( Server serverC:16805):1024, 10.237.110.225( > Management:6033):1024, 10.237.110.195( Server > serverB:9993):1024, 10.237.110.194( Server > serverA:632):1024]] > > The connection between the systems was verified with tcpdumps, udp 1024 is > running fine. > > We have tried redeploying the service and making numerous attempts but we > always get the same error during startup. > Any idea? Thank you. > Marco. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9906) Unable to reconnect a node after SO patching "15 seconds have elapsed while waiting for replies"
[ https://issues.apache.org/jira/browse/GEODE-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales resolved GEODE-9906. --- Resolution: Won't Fix Relates to version 1.0.0-incubating > Unable to reconnect a node after SO patching "15 seconds have elapsed while > waiting for replies" > > > Key: GEODE-9906 > URL: https://issues.apache.org/jira/browse/GEODE-9906 > Project: Geode > Issue Type: Bug >Reporter: Marco Baldessari >Priority: Major > > I have a cluster situation consisting of 4 total nodes, 3 servers and 1 > management node, working properly. > At the beginning of the month we planned to patch the OS and we started from > the first server node with this procedure: > - Stop service > - S.O. patching > - Server restart > - Start service > The service of the first patched node named "serverA" fails to restart with > this error: > Log entries cluster join: > serverA: > | INFO | region-dm-12 | ache.geode.internal.tcp.Connection | > --> Connection: shared=true ordered=false failed to connect to peer > 10.237.110.195( Server serverB:9993):1024 because: > java.net.ConnectException: Connection timed out (Connection timed out) > | WARN | region-dm-12 | ache.geode.internal.tcp.Connection | > --> Connection: Attempting reconnect to peer 10.237.110.195( Server > serverB:9993):1024 > > ServerMgmt: > | WARN | pool-3-thread-1 | tributed.internal.ReplyProcessor21 > | --> 15 seconds have elapsed while waiting for replies: > from [10.237.110.194( Server serverA:632):1024]> on 10.237.110.225( > Management:6033):1024 whose current membership list is: > [[10.237.110.196( Server serverC:16805):1024, 10.237.110.225( > Management:6033):1024, 10.237.110.195( Server > serverB:9993):1024, 10.237.110.194( Server > serverA:632):1024]] > > The connection between the systems was verified with tcpdumps, udp 1024 is > running fine. > > We have tried redeploying the service and making numerous attempts but we > always get the same error during startup. > Any idea? Thank you. > Marco. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10293) Replace LGTM with CodeQL on PR checks
[ https://issues.apache.org/jira/browse/GEODE-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-10293. - Fix Version/s: 1.16.0 Resolution: Fixed > Replace LGTM with CodeQL on PR checks > - > > Key: GEODE-10293 > URL: https://issues.apache.org/jira/browse/GEODE-10293 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.16.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > Geode is having issues with LGTM timing out, which impedes PR approval. Try > moving to GitHub CodeQL actions instead. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9894) CI Failure: RedundancyLevelPart1DUnitTest > testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest
[
https://issues.apache.org/jira/browse/GEODE-9894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-9894:
--
Description:
{code:java}
{{> Task :geode-core:distributedTest
RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest FAILED
org.awaitility.core.ConditionTimeoutException: Assertion condition defined
as a org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest
Expecting value to be true but was false within 5 minutes.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest(RedundancyLevelPart1DUnitTest.java:326)
Caused by:
org.opentest4j.AssertionFailedError:
Expecting value to be true but was false
at sun.reflect.GeneratedConstructorAccessor25.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.lambda$testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest$13(RedundancyLevelPart1DUnitTest.java:329)}}
{code}
was:
{{> Task :geode-core:distributedTest
RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest FAILED
org.awaitility.core.ConditionTimeoutException: Assertion condition defined
as a org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest
Expecting value to be true but was false within 5 minutes.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest(RedundancyLevelPart1DUnitTest.java:326)
Caused by:
org.opentest4j.AssertionFailedError:
Expecting value to be true but was false
at sun.reflect.GeneratedConstructorAccessor25.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.lambda$testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest$13(RedundancyLevelPart1DUnitTest.java:329)}}
> CI Failure: RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest
> -
>
> Key: GEODE-9894
> URL: https://issues.apache.org/jira/browse/GEODE-9894
> Project: Geode
> Issue Type: Bug
> Components: client queues, client/server
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Priority: Major
>
> {code:java}
> {{> Task :geode-core:distributedTest
> RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest
> Expecting value to be true but was false within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByUnregisterInterest(RedundancyLevelPart1DUnitTest.java:326)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
>
[jira] [Updated] (GEODE-9895) CI Failure: ConnectionPoolDUnitTest > basicTestLifetimeExpire
[
https://issues.apache.org/jira/browse/GEODE-9895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-9895:
--
Description:
{code:java}
{{ConnectionPoolDUnitTest > basicTestLifetimeExpire FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
on Host
heavy-lifter-8ad734f8-fc08-5ba3-bad2-7388aa23c427.c.apachegeode-ci.internal
with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
at
org.apache.geode.cache.ConnectionPoolDUnitTest.basicTestLifetimeExpire(ConnectionPoolDUnitTest.java:813)
Caused by:
org.apache.geode.cache.client.ServerOperationException: remote server
on
heavy-lifter-8ad734f8-fc08-5ba3-bad2-7388aa23c427(121494:loner):40384:38a873a8:
: While performing a remote put
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:372)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:274)
at
org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:221)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805)
at
org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:92)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:158)
at
org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3045)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3160)
at
org.apache.geode.internal.cache.map.RegionMapPut.invokeCacheWriter(RegionMapPut.java:244)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutIfPreconditionsSatisified(AbstractRegionMapPut.java:295)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnSynchronizedRegionEntry(AbstractRegionMapPut.java:282)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnRegionEntryInMap(AbstractRegionMapPut.java:273)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.addRegionEntryToMapAndDoPut(AbstractRegionMapPut.java:251)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutRetryingIfNeeded(AbstractRegionMapPut.java:216)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doWithIndexInUpdateMode(AbstractRegionMapPut.java:198)
at
org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:180)
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:2045)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5615)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5593)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5050)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1646)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1633)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:445)
at
org.apache.geode.cache.ConnectionPoolDUnitTest.lambda$basicTestLifetimeExpire$f09ad7da$1(ConnectionPoolDUnitTest.java:825)
Caused by:
org.apache.geode.cache.RegionDestroyedException: Server connection
from [identity(10.0.2.7(121494:loner):40384:38a873a8,connection=1; port=40384]:
Region named /root/basicTestLifetimeExpire was not found during put request
at
org.apache.geode.in
[jira] [Commented] (GEODE-10293) Replace LGTM with CodeQL on PR checks
[ https://issues.apache.org/jira/browse/GEODE-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534587#comment-17534587 ] ASF subversion and git services commented on GEODE-10293: - Commit 64d07164edd84391db61f3118486083f3a9169e1 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=64d07164ed ] GEODE-10293: Modify .asf.yaml to require CodeQL, drop LGTM (#7674) GEODE-10293: Modify .asf.yaml to require CodeQL, drop LGTM > Replace LGTM with CodeQL on PR checks > - > > Key: GEODE-10293 > URL: https://issues.apache.org/jira/browse/GEODE-10293 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.16.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > Geode is having issues with LGTM timing out, which impedes PR approval. Try > moving to GitHub CodeQL actions instead. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9909) Tomcat8SessionsClientServerDUnitTest > testSessionPersists1 FAILED
[
https://issues.apache.org/jira/browse/GEODE-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag updated GEODE-9909:
---
Affects Version/s: 1.15.0
> Tomcat8SessionsClientServerDUnitTest > testSessionPersists1 FAILED
> --
>
> Key: GEODE-9909
> URL: https://issues.apache.org/jira/browse/GEODE-9909
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.8, 1.15.0
>Reporter: Kristen
>Priority: Major
> Labels: triage
>
> {code:java}
> > Task :extensions:geode-modules-tomcat8:distributedTest
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest >
> testSessionPersists1 FAILED
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection
> refused){code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-6408) CI Failure: ParallelWANPropagationDUnitTest.testParallelColocatedPropagation2
[
https://issues.apache.org/jira/browse/GEODE-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534571#comment-17534571
]
Geode Integration commented on GEODE-6408:
--
Seen in [distributed-test-openjdk8
#351|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/351]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1156/test-results/distributedTest/1651861483/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1156/test-artifacts/1651861483/distributedtestfiles-openjdk8-1.15.0-build.1156.tgz].
> CI Failure: ParallelWANPropagationDUnitTest.testParallelColocatedPropagation2
> -
>
> Key: GEODE-6408
> URL: https://issues.apache.org/jira/browse/GEODE-6408
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bruce J Schuchardt
>Priority: Major
>
>
>
> {noformat}
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest
> > testParallelColocatedPropagation2 FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest$$Lambda$413/1673457629.run
> in VM 4 running on Host 4ad218d121f9 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:557)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:384)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest.testParallelColocatedPropagation2(ParallelWANPropagationDUnitTest.java:444)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.WANTestBase that uses
> org.apache.geode.internal.cache.wan.AbstractGatewaySender,
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderorg.apache.geode.internal.cache.RegionQueue
> Expected events in all secondary queues are drained but actual is 120. Queue
> content is: bucketId=9:[809, 909, 509, 309, 1009, 709, 109, 209, 409,
> 609];bucketId=57:[557, 757, 257, 157, 357, 1057, 657, 457, 857,
> 957];bucketId=21:[221, 621, 421, 521, 721, 821, 121, 1021, 921,
> 321];bucketId=72:[972, 672, 172, 1072, 272, 472, 372, 872, 772,
> 572];bucketId=95:[495, 895, 295, 1095, 995, 795, 695, 595, 395,
> 195];bucketId=61:[461, 861, 761, 261, 961, 161, 561, 1061, 361,
> 661];bucketId=87:[887, 287, 1087, 787, 987, 687, 587, 387, 187,
> 487];bucketId=34:[234, 934, 1034, 734, 534, 634, 834, 434, 134,
> 334];bucketId=50:[350, 150, 1050, 650, 750, 550, 450, 850, 950,
> 250];bucketId=73:[673, 973, 773, 173, 273, 473, 373, 873, 1073,
> 573];bucketId=18:[718, 618, 218, 1018, 418, 918, 318, 818, 118,
> 518];bucketId=99:[199, 999, 899, 699, 599, 299, 499, 399, 1099, 799];
> expected:<0> but was:<120> within 300 seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.wan.WANTestBase.validateParallelSenderQueueAllBucketsDrained(WANTestBase.java:3291)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest.lambda$testParallelColocatedPropagation2$bb17a952$14(ParallelWANPropagationDUnitTest.java:444)
> Caused by:
> java.lang.AssertionError: Expected events in all secondary queues
> are drained but actual is 120. Queue content is: bucketId=9:[809, 909, 509,
> 309, 1009, 709, 109, 209, 409, 609];bucketId=57:[557, 757, 257, 157, 357,
> 1057, 657, 457, 857, 957];bucketId=21:[221, 621, 421, 521, 721, 821, 121,
> 1021, 921, 321];bucketId=72:[972, 672, 172, 1072, 272, 472, 372, 872, 772,
> 572];bucketId=95:[495, 895, 295, 1095, 995, 795, 695, 595, 395,
> 195];bucketId=61:[461, 861, 761, 261, 961, 161, 561, 1061, 361,
> 661];bucketId=87:[887, 287, 1087, 787, 987, 687, 587, 387, 187,
> 487];bucketId=34:[234, 934, 1034, 734, 534, 634, 834, 434, 134,
> 334];bucketId=50:[350, 150, 1050, 650, 750, 550, 450, 850, 950,
> 250];bucketId=73:[673, 973, 773, 173, 273, 473, 373, 873, 1073,
> 573];bucketId=18:[718, 618, 218, 1018, 418, 918, 318, 818, 118,
> 518];bucketId=99:[199, 999, 899, 699, 599, 299, 499, 399, 1099, 799];
> expected:<0> but was:<120>
> {noformat}
>
> arti
[jira] [Updated] (GEODE-6408) CI Failure: ParallelWANPropagationDUnitTest.testParallelColocatedPropagation2
[
https://issues.apache.org/jira/browse/GEODE-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag updated GEODE-6408:
---
Affects Version/s: 1.15.0
> CI Failure: ParallelWANPropagationDUnitTest.testParallelColocatedPropagation2
> -
>
> Key: GEODE-6408
> URL: https://issues.apache.org/jira/browse/GEODE-6408
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bruce J Schuchardt
>Priority: Major
>
>
>
> {noformat}
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest
> > testParallelColocatedPropagation2 FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest$$Lambda$413/1673457629.run
> in VM 4 running on Host 4ad218d121f9 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:557)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:384)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest.testParallelColocatedPropagation2(ParallelWANPropagationDUnitTest.java:444)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.WANTestBase that uses
> org.apache.geode.internal.cache.wan.AbstractGatewaySender,
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderorg.apache.geode.internal.cache.RegionQueue
> Expected events in all secondary queues are drained but actual is 120. Queue
> content is: bucketId=9:[809, 909, 509, 309, 1009, 709, 109, 209, 409,
> 609];bucketId=57:[557, 757, 257, 157, 357, 1057, 657, 457, 857,
> 957];bucketId=21:[221, 621, 421, 521, 721, 821, 121, 1021, 921,
> 321];bucketId=72:[972, 672, 172, 1072, 272, 472, 372, 872, 772,
> 572];bucketId=95:[495, 895, 295, 1095, 995, 795, 695, 595, 395,
> 195];bucketId=61:[461, 861, 761, 261, 961, 161, 561, 1061, 361,
> 661];bucketId=87:[887, 287, 1087, 787, 987, 687, 587, 387, 187,
> 487];bucketId=34:[234, 934, 1034, 734, 534, 634, 834, 434, 134,
> 334];bucketId=50:[350, 150, 1050, 650, 750, 550, 450, 850, 950,
> 250];bucketId=73:[673, 973, 773, 173, 273, 473, 373, 873, 1073,
> 573];bucketId=18:[718, 618, 218, 1018, 418, 918, 318, 818, 118,
> 518];bucketId=99:[199, 999, 899, 699, 599, 299, 499, 399, 1099, 799];
> expected:<0> but was:<120> within 300 seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.wan.WANTestBase.validateParallelSenderQueueAllBucketsDrained(WANTestBase.java:3291)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPropagationDUnitTest.lambda$testParallelColocatedPropagation2$bb17a952$14(ParallelWANPropagationDUnitTest.java:444)
> Caused by:
> java.lang.AssertionError: Expected events in all secondary queues
> are drained but actual is 120. Queue content is: bucketId=9:[809, 909, 509,
> 309, 1009, 709, 109, 209, 409, 609];bucketId=57:[557, 757, 257, 157, 357,
> 1057, 657, 457, 857, 957];bucketId=21:[221, 621, 421, 521, 721, 821, 121,
> 1021, 921, 321];bucketId=72:[972, 672, 172, 1072, 272, 472, 372, 872, 772,
> 572];bucketId=95:[495, 895, 295, 1095, 995, 795, 695, 595, 395,
> 195];bucketId=61:[461, 861, 761, 261, 961, 161, 561, 1061, 361,
> 661];bucketId=87:[887, 287, 1087, 787, 987, 687, 587, 387, 187,
> 487];bucketId=34:[234, 934, 1034, 734, 534, 634, 834, 434, 134,
> 334];bucketId=50:[350, 150, 1050, 650, 750, 550, 450, 850, 950,
> 250];bucketId=73:[673, 973, 773, 173, 273, 473, 373, 873, 1073,
> 573];bucketId=18:[718, 618, 218, 1018, 418, 918, 318, 818, 118,
> 518];bucketId=99:[199, 999, 899, 699, 599, 299, 499, 399, 1099, 799];
> expected:<0> but was:<120>
> {noformat}
>
> artifacts are here:
> gs://files-gemfire-dev/builds/gemfire-develop-main/1.9.0-build.0414/test-artifacts/1550092370/distributedtestfiles-OpenJDK8-1.9.0-build.0414.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534568#comment-17534568
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-base
#326|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/326].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534567#comment-17534567
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-base
#327|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/327].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[
https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534565#comment-17534565
]
ASF GitHub Bot commented on GEODE-10218:
pivotal-jbarrett commented on code in PR #954:
URL: https://github.com/apache/geode-native/pull/954#discussion_r869645866
##
clicache/integration-test2/GfshTest.cs:
##
@@ -77,13 +77,16 @@ public void StartLocatorStringsTest()
.withSslKeyStore("some/path/keystore.jks")
.withSslKeyStorePassword("password1")
.withSslTrustStore("some/path/truststore.jks")
-.withSslTrustStorePassword("password2");
+.withSslTrustStorePassword("password2")
+.withDebugAgent(true, "address");
s = locator.ToString();
+var withAttachPortRemoved = s.Substring(0, s.LastIndexOf(":",
s.Length-1, 6));
Review Comment:
"attachPort"?
##
cppcache/integration/framework/Cluster.h:
##
@@ -141,6 +142,9 @@ class Cluster {
Cluster(InitialLocators initialLocators, InitialServers initialServers,
UseIpv6 useIpv6 = UseIpv6{false});
+ Cluster(InitialLocators initialLocators, InitialServers initialServers,
+ UseDebugAgent allowAttach);
Review Comment:
rename variable.
##
cppcache/integration/framework/Cluster.h:
##
@@ -124,6 +124,7 @@ using Password = NamedType;
using CacheXMLFiles =
NamedType, struct CacheXMLFilesParameter>;
using UseIpv6 = NamedType;
+using UseDebugAgent = NamedType;
Review Comment:
Rename struct.
> Launch Cluster with Attachability Flag
> --
>
> Key: GEODE-10218
> URL: https://issues.apache.org/jira/browse/GEODE-10218
> Project: Geode
> Issue Type: Test
> Components: native client
>Reporter: Michael Martell
>Assignee: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> To assist with protocol analysis it is very helpful to be able to step
> through the server code in the Intellij debugger while running native client
> test code. However, to be allowed to set breakpoints in the server code, the
> server must be started with the special flag below:
>
> --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT
> This ticket is to add support for the above flag in the native client test
> frameworks.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9895) CI Failure: ConnectionPoolDUnitTest > basicTestLifetimeExpire
[
https://issues.apache.org/jira/browse/GEODE-9895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534563#comment-17534563
]
Geode Integration commented on GEODE-9895:
--
Seen in [distributed-test-openjdk17
#19|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk17/builds/19]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0202/test-results/distributedTest/1652163089/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0202/test-artifacts/1652163089/distributedtestfiles-openjdk17-1.16.0-build.0202.tgz].
> CI Failure: ConnectionPoolDUnitTest > basicTestLifetimeExpire
> -
>
> Key: GEODE-9895
> URL: https://issues.apache.org/jira/browse/GEODE-9895
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Priority: Major
>
> {{ConnectionPoolDUnitTest > basicTestLifetimeExpire FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-8ad734f8-fc08-5ba3-bad2-7388aa23c427.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.cache.ConnectionPoolDUnitTest.basicTestLifetimeExpire(ConnectionPoolDUnitTest.java:813)
> Caused by:
> org.apache.geode.cache.client.ServerOperationException: remote server
> on
> heavy-lifter-8ad734f8-fc08-5ba3-bad2-7388aa23c427(121494:loner):40384:38a873a8:
> : While performing a remote put
> at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:372)
> at
> org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:274)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:221)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805)
> at
> org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:92)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:158)
> at
> org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3045)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3160)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.invokeCacheWriter(RegionMapPut.java:244)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutIfPreconditionsSatisified(AbstractRegionMapPut.java:295)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnSynchronizedRegionEntry(AbstractRegionMapPut.java:282)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutOnRegionEntryInMap(AbstractRegionMapPut.java:273)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.addRegionEntryToMapAndDoPut(AbstractRegionMapPut.java:251)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPutRetryingIfNeeded(AbstractRegionMapPut.java:216)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doWithIndexInUpdateMode(AbstractRegionMapPut.java:198)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:180)
> 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:2045)
>
[jira] [Commented] (GEODE-10288) Identify multiple JDK versions for upgrade tests
[ https://issues.apache.org/jira/browse/GEODE-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534559#comment-17534559 ] ASF subversion and git services commented on GEODE-10288: - Commit e88ed8392a3391f0b5dd283423ef9a6709c2d979 in geode's branch refs/heads/develop from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e88ed8392a ] GEODE-10288: Define JDK 8, 11, 17 homes for upgrade tests (#7675) > Identify multiple JDK versions for upgrade tests > > > Key: GEODE-10288 > URL: https://issues.apache.org/jira/browse/GEODE-10288 > Project: Geode > Issue Type: Improvement > Components: ci, tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > > An upcoming PR enhances most upgrade tests to upgrade a Geode client, > locator, or server from one JDK version to another. That functionality > requires CI to define environment variables to identify the installed paths > to JDKs for Java 8, 11, and 17 when launching each test JVM. The proposed > environment variables are: > - TEST_JAVA_8_HOME > - TEST_JAVA_11_HOME > - TEST_JAVA_17_HOME -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10294: Assignee: Eric Shu > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10294: -- Labels: needsTriage (was: ) > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
Eric Shu created GEODE-10294: Summary: Need to consider invalid token when comparing value during putIfAbsent Key: GEODE-10294 URL: https://issues.apache.org/jira/browse/GEODE-10294 Project: Geode Issue Type: Bug Components: regions Reporter: Eric Shu During retry of putIfAbsent, there is a possibility that value has been created by the initial operation. Geode treats this as a successful operation, so that client initiated the operation will also create the entry in its local cache. However, putIfAbsent of null is a special case, as an Invalid Token is created instead of null value being put into the region entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10294: - Labels: blocks-1.15.0 (was: needsTriage) > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0 > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10288) Identify multiple JDK versions for upgrade tests
[ https://issues.apache.org/jira/browse/GEODE-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10288: --- Labels: Java17 pull-request-available (was: Java17) > Identify multiple JDK versions for upgrade tests > > > Key: GEODE-10288 > URL: https://issues.apache.org/jira/browse/GEODE-10288 > Project: Geode > Issue Type: Improvement > Components: ci, tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > > An upcoming PR enhances most upgrade tests to upgrade a Geode client, > locator, or server from one JDK version to another. That functionality > requires CI to define environment variables to identify the installed paths > to JDKs for Java 8, 11, and 17 when launching each test JVM. The proposed > environment variables are: > - TEST_JAVA_8_HOME > - TEST_JAVA_11_HOME > - TEST_JAVA_17_HOME -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10293) Replace LGTM with CodeQL on PR checks
[ https://issues.apache.org/jira/browse/GEODE-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10293: --- Labels: pull-request-available (was: ) > Replace LGTM with CodeQL on PR checks > - > > Key: GEODE-10293 > URL: https://issues.apache.org/jira/browse/GEODE-10293 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.16.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > Geode is having issues with LGTM timing out, which impedes PR approval. Try > moving to GitHub CodeQL actions instead. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10293) Replace LGTM with CodeQL on PR checks
Robert Houghton created GEODE-10293: --- Summary: Replace LGTM with CodeQL on PR checks Key: GEODE-10293 URL: https://issues.apache.org/jira/browse/GEODE-10293 Project: Geode Issue Type: Task Components: ci Affects Versions: 1.16.0 Reporter: Robert Houghton Geode is having issues with LGTM timing out, which impedes PR approval. Try moving to GitHub CodeQL actions instead. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10282) Migrate from springfox to springdoc
[ https://issues.apache.org/jira/browse/GEODE-10282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534524#comment-17534524 ] ASF subversion and git services commented on GEODE-10282: - Commit 9fbd35a8f9816d4c9baf98d7fec38c5850686177 in geode's branch refs/heads/develop from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9fbd35a8f9 ] GEODE-10282: Migrate from springfox to springdoc (#7659) springfox swagger is no longer maintained, so springdoc is the best choice going forward. > Migrate from springfox to springdoc > --- > > Key: GEODE-10282 > URL: https://issues.apache.org/jira/browse/GEODE-10282 > Project: Geode > Issue Type: Task > Components: rest (admin), rest (dev) >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > Replace springfox with springdoc because springfox is no longer active. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[
https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534513#comment-17534513
]
ASF GitHub Bot commented on GEODE-10218:
mmartell commented on code in PR #954:
URL: https://github.com/apache/geode-native/pull/954#discussion_r869537870
##
clicache/integration-test2/Cluster.cs:
##
@@ -71,7 +73,7 @@ private bool StartLocators()
for (var i = 0; i < locatorCount_; i++)
{
var locator = new Locator(this, new List(),
-name_ + "/locator/" + i.ToString(), i == 0);
+name_ + "/locator/" + i.ToString(), i == 0, allowAttach_);
Review Comment:
Done.
> Launch Cluster with Attachability Flag
> --
>
> Key: GEODE-10218
> URL: https://issues.apache.org/jira/browse/GEODE-10218
> Project: Geode
> Issue Type: Test
> Components: native client
>Reporter: Michael Martell
>Assignee: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> To assist with protocol analysis it is very helpful to be able to step
> through the server code in the Intellij debugger while running native client
> test code. However, to be allowed to set breakpoints in the server code, the
> server must be started with the special flag below:
>
> --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT
> This ticket is to add support for the above flag in the native client test
> frameworks.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10061) Mass-Test-Run: ReconnectDUnitTest > testReconnectWithRoleLoss
[
https://issues.apache.org/jira/browse/GEODE-10061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales resolved GEODE-10061.
Resolution: Not A Problem
Failure due to resource issue. It will probably happen again, but I don't think
this particular ticket needs to be reopened. If this becomes a serious issue
then we need to write a new ticket for it, as it is more related to our
infrastructure than the test itself.
> Mass-Test-Run: ReconnectDUnitTest > testReconnectWithRoleLoss
> -
>
> Key: GEODE-10061
> URL: https://issues.apache.org/jira/browse/GEODE-10061
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
>
> {code:java}
> > Task :geode-core:distributedTest
> PRClientServerRegionFunctionExecutionDUnitTest >
> testserverMultiKeyExecution_ThrowException[ExecuteFunctionById] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.execute.PRClientServerRegionFunctionExecutionDUnitTest$$Lambda$337/1157292204.run
> in VM 3 running on Host
> heavy-lifter-36926f81-68ee-5ab9-b87b-3d77805b70b1.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.internal.cache.execute.PRClientServerRegionFunctionExecutionDUnitTest.testserverMultiKeyExecution_ThrowException(PRClientServerRegionFunctionExecutionDUnitTest.java:379)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected Socket closed connection=Pooled Connection to
> heavy-lifter-36926f81-68ee-5ab9-b87b-3d77805b70b1.c.apachegeode-ci.internal:20923,heavy-lifter-36926f81-68ee-5ab9-b87b-3d77805b70b1(304549):42669:
> Connection[DESTROYED] attempt=3). Server unreachable: could not connect
> after 3 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:671)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:502)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:155)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805)
> at
> org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:92)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:158)
> at
> org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3048)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3163)
> at
> org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5620)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5598)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5053)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1649)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1636)
> at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:445)
> at
> org.apache.geode.internal.cache.execute.PRClientServerRegionFunctionExecutionDUnitTest.serverMultiKeyExecution_ThrowException(PRClientServerRegionFunctionExecutionDUnitTest.java:916)
> at
> org.apache.geode.internal.cache.execute.PRClientServerRegionFunctionExecutionDUnitTest.lambda$testserverMultiKeyExecution_ThrowException$bb17a952$1(PRClientServerRegionFunctionExecutionDUnitTest.java:380)
> Caused by:
> java.net.SocketException: Socket closed
> at java.net.SocketInputStream.read(SocketInputStream.java:204)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> ...
> {code}
> {code:java}
> ReconnectDUnitTest > testReconnectWithRoleLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 444
> [fatal 2022/02/12 20:58:08.620 UTC receiver,heavy-lifter-36926f81-68e
[jira] [Commented] (GEODE-10284) Add partition-listener option to gfsh create region command
[
https://issues.apache.org/jira/browse/GEODE-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534498#comment-17534498
]
ASF subversion and git services commented on GEODE-10284:
-
Commit 610a864544d5dc53155fdcd8ec55b7c233a24b4b in geode's branch
refs/heads/support/1.15 from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=610a864544 ]
GEODE-10284: Add partition-listener option to gfsh create region command
(#7666) (#7671)
* Update documentation
Co-authored-by: Dave Barnes
(cherry picked from commit d4b80d27277d3eda22f692cf95d95026096470d5)
> Add partition-listener option to gfsh create region command
> ---
>
> Key: GEODE-10284
> URL: https://issues.apache.org/jira/browse/GEODE-10284
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> This adds a {{--partition-listener}} option to the {{create region}} gfsh
> command. I'm not sure why this was not added in the first place since all the
> plumbing to support it already seems to exist.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10081) Freeze during launch of locator
[
https://issues.apache.org/jira/browse/GEODE-10081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10081:
---
Description:
We are using gfsh with a script to automatically launch a locator and a server.
During the launch of the locator, the process gfsh just freezes randomly. The
locator process is forked, but gfsh remains frozen.
A jstack on the process shows that the process is stuck on an internal
NativeLibrary.load call. This one happens when gfsh try to attach to the
process : internally the jvm loads the libattach.so library, but the call never
return.
To be complete, Geode is here deployed inside a docker container, using ubi8 as
base image, java is jdk11.0.11 - we have tested with 11.0.13, same issue.
The stack is the following (full jstack dump attached)
{code:java}
"main" #1 prio=5 os_prio=0 cpu=2402.78ms elapsed=1924.45s allocated=236M
defined_classes=10346 tid=0x7fc904024000 nid=0x16 runnable
[0x7fc90a84a000]
java.lang.Thread.State: RUNNABLE
at java.lang.ClassLoader$NativeLibrary.load0(java.base@11.0.11/Native
Method)
at java.lang.ClassLoader$NativeLibrary.load(java.base@11.0.11/Unknown
Source)
at
java.lang.ClassLoader$NativeLibrary.loadLibrary(java.base@11.0.11/Unknown
Source)
- locked <0x823efe60> (a java.util.HashSet)
at java.lang.ClassLoader.loadLibrary0(java.base@11.0.11/Unknown Source)
at java.lang.ClassLoader.loadLibrary(java.base@11.0.11/Unknown Source)
at java.lang.Runtime.loadLibrary0(java.base@11.0.11/Unknown Source)
- locked <0x828224b8> (a java.lang.Runtime)
at java.lang.System.loadLibrary(java.base@11.0.11/Unknown Source)
at sun.tools.attach.VirtualMachineImpl.(jdk.attach@11.0.11/Unknown
Source)
at
sun.tools.attach.AttachProviderImpl.attachVirtualMachine(jdk.attach@11.0.11/Unknown
Source)
at com.sun.tools.attach.VirtualMachine.attach(jdk.attach@11.0.11/Unknown
Source)
at
org.apache.geode.internal.process.MBeanProcessController.getJMXServiceURL(MBeanProcessController.java:227)
at
org.apache.geode.internal.process.MBeanProcessController.connect(MBeanProcessController.java:192)
at
org.apache.geode.internal.process.MBeanProcessController.invokeOperationOnTargetMBean(MBeanProcessController.java:159)
at
org.apache.geode.internal.process.MBeanProcessController.status(MBeanProcessController.java:136)
at
org.apache.geode.internal.process.MBeanProcessController.status(MBeanProcessController.java:81)
at
org.apache.geode.internal.process.MBeanOrFileProcessController.status(MBeanOrFileProcessController.java:37)
at
org.apache.geode.distributed.LocatorLauncher.statusWithWorkingDirectory(LocatorLauncher.java:1012)
at
org.apache.geode.distributed.LocatorLauncher.status(LocatorLauncher.java:940)
at
org.apache.geode.distributed.LocatorLauncher$LocatorState.fromDirectory(LocatorLauncher.java:2077)
at
org.apache.geode.management.internal.cli.commands.StartLocatorCommand.doStartLocator(StartLocatorCommand.java:267)
at
org.apache.geode.management.internal.cli.commands.StartLocatorCommand.startLocator(StartLocatorCommand.java:133)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.11/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.11/Unknown
Source)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.11/Unknown
Source)
at java.lang.reflect.Method.invoke(java.base@11.0.11/Unknown Source)
at
org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:282)
at
org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:139)
at
org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:149)
{code}
was:
We are using gfsh with a script to automatically launch a locator and a server.
During the launch of the locator, the process gfsh just freezes randomly. The
locator process is forked, but gfsh remains frozen.
A jstack on the process shows that the process is stuck on an internal
NativeLibrary.load call. This one happens when gfsh try to attach to the
process : internally the jvm loads the libattach.so library, but the call never
return.
To be complete, Geode is here deployed inside a docker container, using ubi8 as
base image, java is jdk11.0.11 - we have tested with 11.0.13, same issue.
The stack is the following (full jstack dump attached)
"main" #1 prio=5 os_prio=0 cpu=2402.78ms elapsed=1924.45s allocated=236M
defined_classes=10346 tid=0x7fc904024000 nid=0x16 runnable
[0x7fc90a84a000]
java.lang.Thread.State: RUNNABLE
at java.lang.ClassLoader$NativeLibrary.load0(java.base@11.0.11/Native
Method)
at java.lang.ClassLoader$NativeLibrary.load(java.base@11.0.11/Unknown
Source)
at
java.lang.ClassLoader$NativeLibrary.load
[jira] [Assigned] (GEODE-10286) cache close in response to a forced disconnect with persistent regions may skip some cleanup
[
https://issues.apache.org/jira/browse/GEODE-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10286:
---
Assignee: Jinmei Liao
> cache close in response to a forced disconnect with persistent regions may
> skip some cleanup
> -
>
> Key: GEODE-10286
> URL: https://issues.apache.org/jira/browse/GEODE-10286
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> During a cache close, persistent regions may not cleanup as much as they
> should. This is because when the PersistentAdvisor is closed, CancelException
> is not handled causing other parts of the close to be skipped. I think the
> place to handle it is:
> DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564). Here
> is an exception showing what it looks like when this happens:
> {noformat}
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on rs-RunItNow-ZH1504a1i3xlarge-hydra-client-10(dataStor
> egemfire2_host1_421:421):41004 started at Wed Mar 23 17:11:48 PDT
> 2022: Member isn't responding to heartbeat requests, caused by org.apac
> he.geode.ForcedDisconnectException: Member isn't responding to heartbeat
> requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:289
> 3)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.ClusterElderManager.getElderId(ClusterElderManager.java:76)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.getElderId(ClusterDistributionManager.java:2085)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getElderId(DLockService.java:254)
> at
> org.apache.geode.distributed.internal.locks.DLockService.notLockGrantorId(DLockService.java:824)
> at
> org.apache.geode.distributed.internal.locks.DLockService.unlock(DLockService.java:1807)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.releaseTieLock(PersistenceAdvisorImpl.java:1181)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.close(PersistenceAdvisorImpl.java:1158)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564)
> at
> org.apache.geode.internal.cache.DistributedRegion.postDestroyRegion(DistributedRegion.java:2657)
> at
> org.apache.geode.internal.cache.LocalRegion.recursiveDestroyRegion(LocalRegion.java:2732)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6241)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1834)
> at
> org.apache.geode.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7320)
> at
> org.apache.geode.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2691)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2308)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2154)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1538)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2545)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2408)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1254)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2329)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:23
[jira] [Updated] (GEODE-10132) org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest Failed
[
https://issues.apache.org/jira/browse/GEODE-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10132:
---
Description:
cannotStopServerByNameWhenNotConnected
{code:java}
org.opentest4j.AssertionFailedError: [Exit value from process started by
[fcdfe561432081bf: gfsh -e start locator --name=locator -e start server
--name=server --server-port=0]]
expected: 0
but was: 1
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:129)
at
org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.startCluster(StopServerAcceptanceTest.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[jira] [Assigned] (GEODE-10289) Add an argument file that opens all JDK packages to all unnamed modules
[
https://issues.apache.org/jira/browse/GEODE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10289:
--
Assignee: Dale Emery
> Add an argument file that opens all JDK packages to all unnamed modules
> ---
>
> Key: GEODE-10289
> URL: https://issues.apache.org/jira/browse/GEODE-10289
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
>
> Certain Geode functionality requires user-defined objects to be accessible
> for reflection. It can be difficult for users to identify non-opened JDK
> packages that are included in their objects.
> Add an argument file that opens all JDK packages to all unnamed modules.
> Adding this argument file when launching a client, locator, or server on JDK
> 17 essentially mimics the {{--illegal-access=permit}} option from JDK 11 (at
> least for JDK packages).
> The supplied argument file will open all packages that come with the Linux
> version of OpenJDK.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10289) Add an argument file that opens all JDK packages to all unnamed modules
[
https://issues.apache.org/jira/browse/GEODE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10289:
---
Labels: Java17 pull-request-available (was: Java17)
> Add an argument file that opens all JDK packages to all unnamed modules
> ---
>
> Key: GEODE-10289
> URL: https://issues.apache.org/jira/browse/GEODE-10289
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
>
> Certain Geode functionality requires user-defined objects to be accessible
> for reflection. It can be difficult for users to identify non-opened JDK
> packages that are included in their objects.
> Add an argument file that opens all JDK packages to all unnamed modules.
> Adding this argument file when launching a client, locator, or server on JDK
> 17 essentially mimics the {{--illegal-access=permit}} option from JDK 11 (at
> least for JDK packages).
> The supplied argument file will open all packages that come with the Linux
> version of OpenJDK.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[
https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10148:
---
Description:
{code:java}
JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
java.lang.AssertionError:
Expecting actual:
["GemFire:service=AccessControl,type=Distributed",
"GemFire:service=CacheServer,port=20842,type=Member,member=server-1",
"GemFire:service=CacheServer,port=20846,type=Member,member=server-2",
"GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one",
"GemFire:service=FileUploader,type=Distributed",
"GemFire:service=Locator,type=Member,member=locator-one",
"GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed",
"GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one",
"GemFire:service=Manager,type=Member,member=locator-one",
"GemFire:service=Region,name="/test-region-1",type=Distributed",
"GemFire:service=Region,name="/test-region-1",type=Member,member=server-1",
"GemFire:service=Region,name="/test-region-1",type=Member,member=server-2",
"GemFire:service=Region,name="/test-region-1",type=Member,member=server-3",
"GemFire:service=System,type=Distributed",
"GemFire:type=Member,member=locator-one",
"GemFire:type=Member,member=server-1",
"GemFire:type=Member,member=server-2",
"GemFire:type=Member,member=server-3"]
to contain exactly (and in same order):
["GemFire:service=AccessControl,type=Distributed",
"GemFire:service=CacheServer,port=20842,type=Member,member=server-1",
"GemFire:service=CacheServer,port=20846,type=Member,member=server-2",
"GemFire:service=CacheServer,port=20850,type=Member,member=server-3",
"GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one",
"GemFire:service=FileUploader,type=Distributed",
"GemFire:service=Locator,type=Member,member=locator-one",
"GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed",
"GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one",
"GemFire:service=Manager,type=Member,member=locator-one",
"GemFire:service=Region,name="/test-region-1",type=Distributed",
"GemFire:service=Region,name="/test-region-1",type=Member,member=server-1",
"GemFire:service=Region,name="/test-region-1",type=Member,member=server-2",
"GemFire:service=Region,name="/test-region-1",type=Member,member=server-3",
"GemFire:service=System,type=Distributed",
"GemFire:type=Member,member=locator-one",
"GemFire:type=Member,member=server-1",
"GemFire:type=Member,member=server-2",
"GemFire:type=Member,member=server-3"]
but could not find the following elements:
["GemFire:service=CacheServer,port=20850,type=Member,member=server-3"]
at
org.apache.geode.management.internal.JMXMBeanFederationDUnitTest.MBeanFederationAddRemoveServer(JMXMBeanFederationDUnitTest.java:130)
8352 tests completed, 1 failed, 414 skipped
{code}
was:
JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
java.lang.AssertionError:
Expecting actual:
["GemFire:service=AccessControl,type=Distributed",
"GemFire:service=CacheServer,port=20842,type=Member,member=server-1",
"GemFire:service=CacheServer,port=20846,type=Member,member=server-2",
"GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one",
"GemFire:service=FileUploader,type=Distributed",
"GemFire:service=Locator,type=Member,member=locator-one",
"GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed",
"GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one",
"GemFire:service=Manager,type=Member,member=locator-one",
"GemFire:service=Region,name="/test-region-1",type=Distributed",
"GemFire:service=Region,name="/test-region-1",type=Member,member=server-1",
"GemFire:service=Region,name="/test-region-1",type=Member,member=server-2",
"GemFire:service=Region,name="/test-region-1",type=Member,member=server-3",
"GemFire:service=System,type=Distributed",
"GemFire:type=Member,member=locator-one",
"GemFire:type=Member,member=server-1",
"GemFire:type=Member,member=server-2",
"GemFire:type=Member,member=server-3"]
to contain exactly (and in same order):
["GemFire:service=AccessControl,type=Distributed",
"GemFire:service=CacheServer,port=20842,type=Member,member=server-1",
"GemFire:service=CacheServer,port=20846,type=Member,member=server-2",
"GemFire:service=CacheServer,port=20850,type=Member,member=server-3",
"GemFire:service=DiskSt
[jira] [Updated] (GEODE-10156) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10156:
---
Description:
{code:java}
org.opentest4j.AssertionFailedError: [Exit value from process started by
[4f44cb7de3b710f1: gfsh -e start locator --name=loc1 --port=20846
--http-service-port=0 --J=-Dgemfire.jmx-manager-port=20847 -e start locator
--name=loc2 --port=20848 --http-service-port=0 --locators=localhost[20846]
--J=-Dgemfire.jmx-manager-port=20849 -e start server --name=server1
--server-port=20850 --locators=localhost[20846] -e start server --name=server2
--server-port=20851 --locators=localhost[20846] -e deploy
--dir=/tmp/junit4947263696282150978/junit6257623670577599443]]
expected: 0
but was: 1
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
at
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
at
org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:93)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
[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=17534468#comment-17534468 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk11 #331|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/331] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1154/test-results/distributedTest/1651798153/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1154/test-artifacts/1651798153/distributedtestfiles-openjdk11-1.15.0-build.1154.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.7#820007)
[jira] [Commented] (GEODE-7822) MemoryThresholdsOffHeapDUnitTest has failures
[
https://issues.apache.org/jira/browse/GEODE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534467#comment-17534467
]
Geode Integration commented on GEODE-7822:
--
Seen in [distributed-test-openjdk8
#2278|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2278]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-results/distributedTest/1651946344/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-artifacts/1651946344/distributedtestfiles-openjdk8-1.15.0-build.1156.tgz].
> MemoryThresholdsOffHeapDUnitTest has failures
> -
>
> Key: GEODE-7822
> URL: https://issues.apache.org/jira/browse/GEODE-7822
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> These two failures were seen in mass test runs...
> {noformat}
> testPRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/674
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testPRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call in
> VM 2 running on Host a57bd8581b8d 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.cache.management.MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:1045)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call(MemoryThresholdsOffHeapDUnitTest.java:1077){noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582515952/]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582515952/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz]
> {noformat}
> testDRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/742
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testDRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call in
> VM 2 running on Host b2c673017cde 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.cache.management.MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:667)
> Caused by:
>java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call(MemoryThresholdsOffHeapDUnitTest.java:673)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582626992/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582626992/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[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=17534466#comment-17534466 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2275|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2275] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-results/distributedTest/1651945637/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-artifacts/1651945637/distributedtestfiles-openjdk8-1.15.0-build.1156.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.7#820007)
[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=17534459#comment-17534459 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2243|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2243] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-results/distributedTest/1651921487/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-artifacts/1651921487/distributedtestfiles-openjdk8-1.15.0-build.1156.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.7#820007)
[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=17534460#comment-17534460 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2283|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2283] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-results/distributedTest/1651951753/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-artifacts/1651951753/distributedtestfiles-openjdk8-1.15.0-build.1156.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.7#820007)
[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=17534462#comment-17534462 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2296|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2296] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-results/distributedTest/1651961707/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-artifacts/1651961707/distributedtestfiles-openjdk8-1.15.0-build.1156.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.7#820007)
[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=17534461#comment-17534461 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2287|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2287] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-results/distributedTest/1651954741/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-artifacts/1651954741/distributedtestfiles-openjdk8-1.15.0-build.1156.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.7#820007)
[jira] [Commented] (GEODE-10291) Support Jammy (ubuntu 22.04)
[ https://issues.apache.org/jira/browse/GEODE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534458#comment-17534458 ] ASF GitHub Bot commented on GEODE-10291: pivotal-jbarrett commented on code in PR #968: URL: https://github.com/apache/geode-native/pull/968#discussion_r869462212 ## docker/ubuntu-22.04/Dockerfile: ## @@ -0,0 +1,71 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +FROM ubuntu:22.04 +LABEL maintainer Apache Geode + +USER root +WORKDIR / + +ENV DEBIAN_FRONTEND noninteractive +RUN apt update && \ +apt -yq full-upgrade && \ +apt-get -y install \ +apt-transport-https \ +ca-certificates \ +curl \ +gnupg2 \ +software-properties-common && \ +apt-get -y autoremove && \ +apt-get autoclean + +RUN . /etc/os-release && \ +curl -s https://download.bell-sw.com/pki/GPG-KEY-bellsoft | apt-key add - && \ +apt-add-repository "deb http://apt.bell-sw.com/ stable main" + +RUN apt update && apt -yq full-upgrade && apt-get -y install \ +build-essential \ +libc++-dev \ +libc++abi-dev \ +zlib1g-dev \ +libssl-dev \ +bellsoft-java11 \ +git \ +doxygen \ +graphviz \ +python3-pip \ +clang-format-6.0 && \ Review Comment: Not used by CI. I occasionally use them locally to compile under the alternative platforms when trying to debug a platform specific issue. They get very little love. > Support Jammy (ubuntu 22.04) > > > Key: GEODE-10291 > URL: https://issues.apache.org/jira/browse/GEODE-10291 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Native client should compile on the latest (ubuntu 22.04) operating system. > Consider including a new pipeline as part of this -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9858) Mass-Test-Run failure PingOpDistributedTest. memberShouldCorrectlyRedirectPingMessage
[
https://issues.apache.org/jira/browse/GEODE-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534455#comment-17534455
]
Geode Integration commented on GEODE-9858:
--
Seen in [distributed-test-openjdk8
#2227|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2227]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-results/distributedTest/1651906342/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1156/test-artifacts/1651906342/distributedtestfiles-openjdk8-1.15.0-build.1156.tgz].
> Mass-Test-Run failure PingOpDistributedTest.
> memberShouldCorrectlyRedirectPingMessage
> -
>
> Key: GEODE-9858
> URL: https://issues.apache.org/jira/browse/GEODE-9858
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>
> {noformat}
> java.lang.AssertionError:
> Expecting actual:
> 1638052119621L
> to be greater than:
> 1638052119621L
> at
> org.apache.geode.internal.cache.tier.sockets.PingOpDistributedTest.memberShouldCorrectlyRedirectPingMessage(PingOpDistributedTest.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.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.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder$1.evaluate(SerializableTemporaryFolder.java:130)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeA
[jira] [Commented] (GEODE-10175) CI Failure: PubSubDUnitTest > shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher
[
https://issues.apache.org/jira/browse/GEODE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534449#comment-17534449
]
Hale Bales commented on GEODE-10175:
Duplicates GEODE-10176, except that failure is in a different test:
PubSubDUnitTest >
shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
> CI Failure: PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher
> -
>
> Key: GEODE-10175
> URL: https://issues.apache.org/jira/browse/GEODE-10175
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher
> FAILED
> 15:29:24org.junit.ComparisonFailure: [channel subscription was not
> received]
> 15:29:24Expecting value to be true but was false expected:<[tru]e> but
> was:<[fals]e>
> 15:29:24at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 15:29:24at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 15:29:24at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 15:29:24at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher(PubSubDUnitTest.java:255)
> {code}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-results/distributedTest/1648080229/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-artifacts/1648080229/distributedtestfiles-openjdk8-1.14.5-build.0938.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10291) Support Jammy (ubuntu 22.04)
[ https://issues.apache.org/jira/browse/GEODE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534450#comment-17534450 ] ASF GitHub Bot commented on GEODE-10291: moleske commented on code in PR #968: URL: https://github.com/apache/geode-native/pull/968#discussion_r869449791 ## docker/ubuntu-22.04/Dockerfile: ## @@ -0,0 +1,71 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +FROM ubuntu:22.04 +LABEL maintainer Apache Geode + +USER root +WORKDIR / + +ENV DEBIAN_FRONTEND noninteractive +RUN apt update && \ +apt -yq full-upgrade && \ +apt-get -y install \ +apt-transport-https \ +ca-certificates \ +curl \ +gnupg2 \ +software-properties-common && \ +apt-get -y autoremove && \ +apt-get autoclean + +RUN . /etc/os-release && \ +curl -s https://download.bell-sw.com/pki/GPG-KEY-bellsoft | apt-key add - && \ +apt-add-repository "deb http://apt.bell-sw.com/ stable main" + +RUN apt update && apt -yq full-upgrade && apt-get -y install \ +build-essential \ +libc++-dev \ +libc++abi-dev \ +zlib1g-dev \ +libssl-dev \ +bellsoft-java11 \ +git \ +doxygen \ +graphviz \ +python3-pip \ +clang-format-6.0 && \ Review Comment: lol. I just copied pasted the ubuntu-20.04 dockerfile, so I didn't actually look at anything beyond the from line. I'll clean these up. Also I don't think these are used in ci after another look, they are only here for convenience. Not sure if anyone cares, just an observation > Support Jammy (ubuntu 22.04) > > > Key: GEODE-10291 > URL: https://issues.apache.org/jira/browse/GEODE-10291 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Native client should compile on the latest (ubuntu 22.04) operating system. > Consider including a new pipeline as part of this -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10176) CI Failure: PubSubDUnitTest > shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
[
https://issues.apache.org/jira/browse/GEODE-10176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales resolved GEODE-10176.
Resolution: Duplicate
Duplicated GEODE-1075, which is the same failure but in a different test.
> CI Failure: PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
> ---
>
> Key: GEODE-10176
> URL: https://issues.apache.org/jira/browse/GEODE-10176
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
> FAILED
> 15:29:54org.junit.ComparisonFailure: [channel subscription was not
> received]
> 15:29:54Expecting value to be true but was false expected:<[tru]e> but
> was:<[fals]e>
> 15:29:54at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 15:29:54at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 15:29:54at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 15:29:54at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher(PubSubDUnitTest.java:225)
> {code}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-results/distributedTest/1648080229/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-artifacts/1648080229/distributedtestfiles-openjdk8-1.14.5-build.0938.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10291) Support Jammy (ubuntu 22.04)
[ https://issues.apache.org/jira/browse/GEODE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534434#comment-17534434 ] ASF GitHub Bot commented on GEODE-10291: pivotal-jbarrett commented on PR #966: URL: https://github.com/apache/geode-native/pull/966#issuecomment-1122589756 Looks like CI didn't run. Please post empty commit. > Support Jammy (ubuntu 22.04) > > > Key: GEODE-10291 > URL: https://issues.apache.org/jira/browse/GEODE-10291 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Native client should compile on the latest (ubuntu 22.04) operating system. > Consider including a new pipeline as part of this -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534432#comment-17534432
]
ASF GitHub Bot commented on GEODE-10276:
gaussianrecurrence commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869428049
##
cppcache/src/CacheImpl.hpp:
##
@@ -134,6 +134,12 @@ class APACHE_GEODE_EXPORT CacheImpl {
*/
DistributedSystem& getDistributedSystem();
Review Comment:
Seems feasible :)
> Refactor PDX (de)serialziation code to align it with Java client
>
>
> Key: GEODE-10276
> URL: https://issues.apache.org/jira/browse/GEODE-10276
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> Currently there are the following open issues regarding PDX (de)serialization:
> * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable
> class|https://issues.apache.org/jira/browse/GEODE-9968]
> * [GEODE-9753 - Coredump during PdxSerializable object
> serialization|https://issues.apache.org/jira/browse/GEODE-9753]
> * [GEODE-10220 - Coredump while initializing PdxType
> remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220]
> * [GEODE-10255 - PdxSerializable not working correctly for multiple versions
> of the same class|https://issues.apache.org/jira/browse/GEODE-10255]
> Also, the implementation on this ticket ([GEODE-8212: Reduce connections to
> server to get type id|https://issues.apache.org/jira/browse/GEODE-8212])
> poses some issues with PDX entries which fields are a permutation. Thing is
> that PdxTypes which fields are a permutation might use the wrong offsets,
> leading to a corrupt serialization. This is something that was not taken into
> account at the time of getting this PR merged.
> So this ticket should be reverted and possibly an alternative solution
> proposed.
> In order to tackle these issues, a code refactoring is needed to introduce
> the following implementations:
> * Single type of PdxWriter
> * An implementation PdxReader that tracks unread data, and other that don't.
> * An implementation for PdxInstances that guarantees that fields are
> actually written in alphabetical order, independently of the writeFields call
> order. This should tackle the issue described above regarding GEODE-8212.
> * Also, it'd be ideal to make it so PDX code is cleaner and easier to
> understand, though that's a complex matter, and also, subjective.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10292) Upgrade boost to 1.79.0
[ https://issues.apache.org/jira/browse/GEODE-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534431#comment-17534431 ] ASF GitHub Bot commented on GEODE-10292: pivotal-jbarrett commented on PR #967: URL: https://github.com/apache/geode-native/pull/967#issuecomment-1122588565 Looks like the CI didn't run at all. Post an empty commit and see if it runs. > Upgrade boost to 1.79.0 > --- > > Key: GEODE-10292 > URL: https://issues.apache.org/jira/browse/GEODE-10292 > Project: Geode > Issue Type: Task >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Upgrade boost to 1.79.0 as first step in supporting visual studio 2022 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10291) Support Jammy (ubuntu 22.04)
[ https://issues.apache.org/jira/browse/GEODE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534430#comment-17534430 ] ASF GitHub Bot commented on GEODE-10291: pivotal-jbarrett commented on code in PR #968: URL: https://github.com/apache/geode-native/pull/968#discussion_r869424555 ## docker/ubuntu-22.04/Dockerfile: ## @@ -0,0 +1,71 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +FROM ubuntu:22.04 +LABEL maintainer Apache Geode + +USER root +WORKDIR / + +ENV DEBIAN_FRONTEND noninteractive +RUN apt update && \ +apt -yq full-upgrade && \ +apt-get -y install \ +apt-transport-https \ +ca-certificates \ +curl \ +gnupg2 \ +software-properties-common && \ +apt-get -y autoremove && \ +apt-get autoclean + +RUN . /etc/os-release && \ +curl -s https://download.bell-sw.com/pki/GPG-KEY-bellsoft | apt-key add - && \ +apt-add-repository "deb http://apt.bell-sw.com/ stable main" + +RUN apt update && apt -yq full-upgrade && apt-get -y install \ +build-essential \ +libc++-dev \ +libc++abi-dev \ +zlib1g-dev \ +libssl-dev \ +bellsoft-java11 \ +git \ +doxygen \ +graphviz \ +python3-pip \ +clang-format-6.0 && \ +apt-get -y autoremove && \ +apt-get autoclean + +RUN pip3 install --upgrade pip && \ Review Comment: I think you can cut out the coveralls bits. We haven't really been using it. Then you can cut out pip above too. ## docker/ubuntu-22.04/Dockerfile: ## @@ -0,0 +1,71 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +FROM ubuntu:22.04 +LABEL maintainer Apache Geode + +USER root +WORKDIR / + +ENV DEBIAN_FRONTEND noninteractive +RUN apt update && \ +apt -yq full-upgrade && \ +apt-get -y install \ +apt-transport-https \ +ca-certificates \ +curl \ +gnupg2 \ +software-properties-common && \ +apt-get -y autoremove && \ +apt-get autoclean + +RUN . /etc/os-release && \ +curl -s https://download.bell-sw.com/pki/GPG-KEY-bellsoft | apt-key add - && \ +apt-add-repository "deb http://apt.bell-sw.com/ stable main" + +RUN apt update && apt -yq full-upgrade && apt-get -y install \ +build-essential \ +libc++-dev \ +libc++abi-dev \ +zlib1g-dev \ +libssl-dev \ +bellsoft-java11 \ +git \ +doxygen \ +graphviz \ +python3-pip \ +clang-format-6.0 && \ Review Comment: Gosh, this should probably be clang-format-11. > Support Jammy (ubuntu 22.04) > > > Key: GEODE-10291 > URL: https://issues.apache.org/jira/browse/GEODE-10291 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Native client should compile on the latest (ubuntu 22.04) operating system. > Consider including a new pipeline as part of this -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534385#comment-17534385
]
ASF GitHub Bot commented on GEODE-10276:
gaussianrecurrence commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869351686
##
cppcache/integration/test/PdxInstanceTest.cpp:
##
@@ -268,7 +268,7 @@ TEST(PdxInstanceTest, testPdxInstance) {
pdxTypeFromPdxTypeInstance->equals(*pdxTypeFromPdxTypeInstanceGet,
false))
<< "PdxObjects should be equal.";
- EXPECT_EQ(-960665662, pdxTypeInstance->hashcode())
+ EXPECT_EQ(514863279, pdxTypeInstance->hashcode())
Review Comment:
Damn, I did not thought of the fact that it was possible to use a
PdxInstance as a key. Really thanks for pointing this out,
> Refactor PDX (de)serialziation code to align it with Java client
>
>
> Key: GEODE-10276
> URL: https://issues.apache.org/jira/browse/GEODE-10276
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> Currently there are the following open issues regarding PDX (de)serialization:
> * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable
> class|https://issues.apache.org/jira/browse/GEODE-9968]
> * [GEODE-9753 - Coredump during PdxSerializable object
> serialization|https://issues.apache.org/jira/browse/GEODE-9753]
> * [GEODE-10220 - Coredump while initializing PdxType
> remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220]
> * [GEODE-10255 - PdxSerializable not working correctly for multiple versions
> of the same class|https://issues.apache.org/jira/browse/GEODE-10255]
> Also, the implementation on this ticket ([GEODE-8212: Reduce connections to
> server to get type id|https://issues.apache.org/jira/browse/GEODE-8212])
> poses some issues with PDX entries which fields are a permutation. Thing is
> that PdxTypes which fields are a permutation might use the wrong offsets,
> leading to a corrupt serialization. This is something that was not taken into
> account at the time of getting this PR merged.
> So this ticket should be reverted and possibly an alternative solution
> proposed.
> In order to tackle these issues, a code refactoring is needed to introduce
> the following implementations:
> * Single type of PdxWriter
> * An implementation PdxReader that tracks unread data, and other that don't.
> * An implementation for PdxInstances that guarantees that fields are
> actually written in alphabetical order, independently of the writeFields call
> order. This should tackle the issue described above regarding GEODE-8212.
> * Also, it'd be ideal to make it so PDX code is cleaner and easier to
> understand, though that's a complex matter, and also, subjective.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534381#comment-17534381
]
ASF GitHub Bot commented on GEODE-10276:
pivotal-jbarrett commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869330026
##
cppcache/integration/test/PdxInstanceTest.cpp:
##
@@ -268,7 +268,7 @@ TEST(PdxInstanceTest, testPdxInstance) {
pdxTypeFromPdxTypeInstance->equals(*pdxTypeFromPdxTypeInstanceGet,
false))
<< "PdxObjects should be equal.";
- EXPECT_EQ(-960665662, pdxTypeInstance->hashcode())
+ EXPECT_EQ(514863279, pdxTypeInstance->hashcode())
Review Comment:
Why did this hash code change? Are we certain it matches the same hash that
the server produces for it? If not this can lead to really bad single hop
performance.
##
tests/javaobject/PdxTests/DeliveryAddress.java:
##
@@ -0,0 +1,82 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package PdxTests;
+
+import java.util.Vector;
+import org.apache.geode.pdx.PdxReader;
+import org.apache.geode.pdx.PdxSerializable;
+import org.apache.geode.pdx.PdxWriter;
+
+public class DeliveryAddress implements PdxSerializable
+{
+String _addressLine;
Review Comment:
Geode's Java conventions come from the Google Java Style Guide. Please don't
prefix member variables. Also please make this private.
##
cppcache/integration/test/PdxSerializableTest.cpp:
##
@@ -0,0 +1,157 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include
+
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "DeliveryAddress.hpp"
+
+namespace {
+
+using apache::geode::client::Cache;
+using apache::geode::client::Cacheable;
+using apache::geode::client::CacheableString;
+using apache::geode::client::CacheableVector;
+using apache::geode::client::FunctionService;
+using apache::geode::client::PdxReader;
+using apache::geode::client::PdxSerializable;
+using apache::geode::client::PdxWriter;
+using apache::geode::client::Region;
+using apache::geode::client::RegionShortcut;
+
+using PdxTests::DeliveryAddress;
+
+std::shared_ptr setupRegion(Cache& cache) {
+ auto region = cache.createRegionFactory(RegionShortcut::PROXY)
+.setPoolName("default")
+.create("region");
+
+ return region;
+}
+
+/**
+ * This test perform the following steps:
+ * 1. Writes a version 1 entry of DeliveryAddress named 'entry.v1'
+ * 2. From another cache, fetches the entry 'entry.v1'
+ * 3. From the same cache as step 2, it call function PutDeliveryAddress that
+ *writes a version 2 entry of DeliveryAddress named 'entry.v2'
+ * 4. From another cache, try to fetch the entry 'entry.v2' and it should match
+ *the entry written in step 3
+ *
+ * The purpose of this test is to verify that even if there are 2 versions of
+ * the same PdxSerializable class, the right PdxType will be used during
+ * (de)serialization
+ */
+TEST(PdxSerializableTest, testRightPdxTypeForDiffPdxVersions) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start([&]() {
+cluster.getGfsh()
+.deploy()
+.jar(getFrameworkString(FrameworkVariable::JavaObjectJarPath))
+.execute();
+ });
+ cluster.getGfsh()
+ .create()
+ .region(
[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[ https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534367#comment-17534367 ] ASF GitHub Bot commented on GEODE-10276: gaussianrecurrence commented on PR #969: URL: https://github.com/apache/geode-native/pull/969#issuecomment-1122476087 > I realize this is a draft but was excited to take a peek and noticed this one right away. Yes, this is a WIP, there are some minor changes i yet want to make, and whole lot more of tests that I want to add, given the size of the change > Refactor PDX (de)serialziation code to align it with Java client > > > Key: GEODE-10276 > URL: https://issues.apache.org/jira/browse/GEODE-10276 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > Currently there are the following open issues regarding PDX (de)serialization: > * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable > class|https://issues.apache.org/jira/browse/GEODE-9968] > * [GEODE-9753 - Coredump during PdxSerializable object > serialization|https://issues.apache.org/jira/browse/GEODE-9753] > * [GEODE-10220 - Coredump while initializing PdxType > remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220] > * [GEODE-10255 - PdxSerializable not working correctly for multiple versions > of the same class|https://issues.apache.org/jira/browse/GEODE-10255] > Also, the implementation on this ticket ([GEODE-8212: Reduce connections to > server to get type id|https://issues.apache.org/jira/browse/GEODE-8212]) > poses some issues with PDX entries which fields are a permutation. Thing is > that PdxTypes which fields are a permutation might use the wrong offsets, > leading to a corrupt serialization. This is something that was not taken into > account at the time of getting this PR merged. > So this ticket should be reverted and possibly an alternative solution > proposed. > In order to tackle these issues, a code refactoring is needed to introduce > the following implementations: > * Single type of PdxWriter > * An implementation PdxReader that tracks unread data, and other that don't. > * An implementation for PdxInstances that guarantees that fields are > actually written in alphabetical order, independently of the writeFields call > order. This should tackle the issue described above regarding GEODE-8212. > * Also, it'd be ideal to make it so PDX code is cleaner and easier to > understand, though that's a complex matter, and also, subjective. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534361#comment-17534361
]
ASF GitHub Bot commented on GEODE-10276:
gaussianrecurrence commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869302660
##
cppcache/src/CacheableObjectArray.cpp:
##
@@ -53,6 +54,18 @@ size_t CacheableObjectArray::objectSize() const {
}
return size;
}
+
+std::string CacheableObjectArray::getClassName() const {
+ if (!empty()) {
+auto&& item = *begin();
+
+if (auto pdx = dynamic_cast(item.get())) {
+ return pdx->getClassName();
+}
+ }
+
+ return "java.lang.Object";
Review Comment:
Thanks for pointing it out :)
> Refactor PDX (de)serialziation code to align it with Java client
>
>
> Key: GEODE-10276
> URL: https://issues.apache.org/jira/browse/GEODE-10276
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> Currently there are the following open issues regarding PDX (de)serialization:
> * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable
> class|https://issues.apache.org/jira/browse/GEODE-9968]
> * [GEODE-9753 - Coredump during PdxSerializable object
> serialization|https://issues.apache.org/jira/browse/GEODE-9753]
> * [GEODE-10220 - Coredump while initializing PdxType
> remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220]
> * [GEODE-10255 - PdxSerializable not working correctly for multiple versions
> of the same class|https://issues.apache.org/jira/browse/GEODE-10255]
> Also, the implementation on this ticket ([GEODE-8212: Reduce connections to
> server to get type id|https://issues.apache.org/jira/browse/GEODE-8212])
> poses some issues with PDX entries which fields are a permutation. Thing is
> that PdxTypes which fields are a permutation might use the wrong offsets,
> leading to a corrupt serialization. This is something that was not taken into
> account at the time of getting this PR merged.
> So this ticket should be reverted and possibly an alternative solution
> proposed.
> In order to tackle these issues, a code refactoring is needed to introduce
> the following implementations:
> * Single type of PdxWriter
> * An implementation PdxReader that tracks unread data, and other that don't.
> * An implementation for PdxInstances that guarantees that fields are
> actually written in alphabetical order, independently of the writeFields call
> order. This should tackle the issue described above regarding GEODE-8212.
> * Also, it'd be ideal to make it so PDX code is cleaner and easier to
> understand, though that's a complex matter, and also, subjective.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534354#comment-17534354 ] ASF GitHub Bot commented on GEODE-9753: --- gaussianrecurrence closed pull request #891: GEODE-9753: Solve PDX serialization coredump URL: https://github.com/apache/geode-native/pull/891 > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534353#comment-17534353 ] ASF GitHub Bot commented on GEODE-9753: --- gaussianrecurrence commented on PR #891: URL: https://github.com/apache/geode-native/pull/891#issuecomment-1122456236 Closing this PR as this issue is already addressed in GEODE-10276 > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534349#comment-17534349
]
ASF GitHub Bot commented on GEODE-10276:
pivotal-jbarrett commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869292240
##
cppcache/src/CacheableObjectArray.cpp:
##
@@ -53,6 +54,18 @@ size_t CacheableObjectArray::objectSize() const {
}
return size;
}
+
+std::string CacheableObjectArray::getClassName() const {
+ if (!empty()) {
+auto&& item = *begin();
+
+if (auto pdx = dynamic_cast(item.get())) {
+ return pdx->getClassName();
+}
+ }
+
+ return "java.lang.Object";
Review Comment:
What if we make this string a `const` value in this compilation unit and
change the return type of this method to return `const std::string&` so we
aren't copy constructing strings on return.
> Refactor PDX (de)serialziation code to align it with Java client
>
>
> Key: GEODE-10276
> URL: https://issues.apache.org/jira/browse/GEODE-10276
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> Currently there are the following open issues regarding PDX (de)serialization:
> * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable
> class|https://issues.apache.org/jira/browse/GEODE-9968]
> * [GEODE-9753 - Coredump during PdxSerializable object
> serialization|https://issues.apache.org/jira/browse/GEODE-9753]
> * [GEODE-10220 - Coredump while initializing PdxType
> remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220]
> * [GEODE-10255 - PdxSerializable not working correctly for multiple versions
> of the same class|https://issues.apache.org/jira/browse/GEODE-10255]
> Also, the implementation on this ticket ([GEODE-8212: Reduce connections to
> server to get type id|https://issues.apache.org/jira/browse/GEODE-8212])
> poses some issues with PDX entries which fields are a permutation. Thing is
> that PdxTypes which fields are a permutation might use the wrong offsets,
> leading to a corrupt serialization. This is something that was not taken into
> account at the time of getting this PR merged.
> So this ticket should be reverted and possibly an alternative solution
> proposed.
> In order to tackle these issues, a code refactoring is needed to introduce
> the following implementations:
> * Single type of PdxWriter
> * An implementation PdxReader that tracks unread data, and other that don't.
> * An implementation for PdxInstances that guarantees that fields are
> actually written in alphabetical order, independently of the writeFields call
> order. This should tackle the issue described above regarding GEODE-8212.
> * Also, it'd be ideal to make it so PDX code is cleaner and easier to
> understand, though that's a complex matter, and also, subjective.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9968) Fix deserialization for new fields in PdxSerializable class
[ https://issues.apache.org/jira/browse/GEODE-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534350#comment-17534350 ] ASF GitHub Bot commented on GEODE-9968: --- gaussianrecurrence commented on PR #910: URL: https://github.com/apache/geode-native/pull/910#issuecomment-1122454544 Closing this PR as the fix is already covered in GEODE-10276 > Fix deserialization for new fields in PdxSerializable class > --- > > Key: GEODE-9968 > URL: https://issues.apache.org/jira/browse/GEODE-9968 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* an implementation of a PdxSerializable class > *WHEN* a set of entries have been written for this class > *AND* after a while, the implementation changes, adding new fields > *AND* a new set of entries are written containing some of the added fields > *AND* all of the region entries are read > *THEN* added fields of the latest entries are empty or contain garbage instead > > *Additional information.* After analyzing Java implementation for > PdxSerializable deserialization, it seems that the client fetches the > PdxFields from the remote PdxType, but instead for the C++ implementation, > code is different as it uses a mapping called "Local2Remote" (which I suppose > it's an optimization). And the current use of this "Local2Remote" mapping is > not working correctly under the described scenario. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9968) Fix deserialization for new fields in PdxSerializable class
[ https://issues.apache.org/jira/browse/GEODE-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534351#comment-17534351 ] ASF GitHub Bot commented on GEODE-9968: --- gaussianrecurrence closed pull request #910: GEODE-9968: Fix new attrs in PdxSerializable URL: https://github.com/apache/geode-native/pull/910 > Fix deserialization for new fields in PdxSerializable class > --- > > Key: GEODE-9968 > URL: https://issues.apache.org/jira/browse/GEODE-9968 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* an implementation of a PdxSerializable class > *WHEN* a set of entries have been written for this class > *AND* after a while, the implementation changes, adding new fields > *AND* a new set of entries are written containing some of the added fields > *AND* all of the region entries are read > *THEN* added fields of the latest entries are empty or contain garbage instead > > *Additional information.* After analyzing Java implementation for > PdxSerializable deserialization, it seems that the client fetches the > PdxFields from the remote PdxType, but instead for the C++ implementation, > code is different as it uses a mapping called "Local2Remote" (which I suppose > it's an optimization). And the current use of this "Local2Remote" mapping is > not working correctly under the described scenario. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[ https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534347#comment-17534347 ] ASF GitHub Bot commented on GEODE-10276: pivotal-jbarrett commented on PR #969: URL: https://github.com/apache/geode-native/pull/969#issuecomment-1122447052 OMG! Awesome effort! > Refactor PDX (de)serialziation code to align it with Java client > > > Key: GEODE-10276 > URL: https://issues.apache.org/jira/browse/GEODE-10276 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > Currently there are the following open issues regarding PDX (de)serialization: > * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable > class|https://issues.apache.org/jira/browse/GEODE-9968] > * [GEODE-9753 - Coredump during PdxSerializable object > serialization|https://issues.apache.org/jira/browse/GEODE-9753] > * [GEODE-10220 - Coredump while initializing PdxType > remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220] > * [GEODE-10255 - PdxSerializable not working correctly for multiple versions > of the same class|https://issues.apache.org/jira/browse/GEODE-10255] > Also, the implementation on this ticket ([GEODE-8212: Reduce connections to > server to get type id|https://issues.apache.org/jira/browse/GEODE-8212]) > poses some issues with PDX entries which fields are a permutation. Thing is > that PdxTypes which fields are a permutation might use the wrong offsets, > leading to a corrupt serialization. This is something that was not taken into > account at the time of getting this PR merged. > So this ticket should be reverted and possibly an alternative solution > proposed. > In order to tackle these issues, a code refactoring is needed to introduce > the following implementations: > * Single type of PdxWriter > * An implementation PdxReader that tracks unread data, and other that don't. > * An implementation for PdxInstances that guarantees that fields are > actually written in alphabetical order, independently of the writeFields call > order. This should tackle the issue described above regarding GEODE-8212. > * Also, it'd be ideal to make it so PDX code is cleaner and easier to > understand, though that's a complex matter, and also, subjective. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[ https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10276: --- Labels: pull-request-available (was: ) > Refactor PDX (de)serialziation code to align it with Java client > > > Key: GEODE-10276 > URL: https://issues.apache.org/jira/browse/GEODE-10276 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > Currently there are the following open issues regarding PDX (de)serialization: > * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable > class|https://issues.apache.org/jira/browse/GEODE-9968] > * [GEODE-9753 - Coredump during PdxSerializable object > serialization|https://issues.apache.org/jira/browse/GEODE-9753] > * [GEODE-10220 - Coredump while initializing PdxType > remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220] > * [GEODE-10255 - PdxSerializable not working correctly for multiple versions > of the same class|https://issues.apache.org/jira/browse/GEODE-10255] > Also, the implementation on this ticket ([GEODE-8212: Reduce connections to > server to get type id|https://issues.apache.org/jira/browse/GEODE-8212]) > poses some issues with PDX entries which fields are a permutation. Thing is > that PdxTypes which fields are a permutation might use the wrong offsets, > leading to a corrupt serialization. This is something that was not taken into > account at the time of getting this PR merged. > So this ticket should be reverted and possibly an alternative solution > proposed. > In order to tackle these issues, a code refactoring is needed to introduce > the following implementations: > * Single type of PdxWriter > * An implementation PdxReader that tracks unread data, and other that don't. > * An implementation for PdxInstances that guarantees that fields are > actually written in alphabetical order, independently of the writeFields call > order. This should tackle the issue described above regarding GEODE-8212. > * Also, it'd be ideal to make it so PDX code is cleaner and easier to > understand, though that's a complex matter, and also, subjective. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[ https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534346#comment-17534346 ] ASF GitHub Bot commented on GEODE-10276: gaussianrecurrence opened a new pull request, #969: URL: https://github.com/apache/geode-native/pull/969 - Code related to PDX de(serialization) has been refactored and aligned (in all possible means) to the Java client, solving the following issues: * GEODE-9968 - Fix deserialization for new fields in PdxSerializable class * GEODE-9753 - Coredump during PdxSerializable object serialization * GEODE-10220 - Coredump while initializing PdxType remoteToLocal * GEODE-10255 - PdxSerializable not working correctly for multiple versions of the same class - Reverted GEODE-8212, to solve potential issues during (de)serialization. This is due to the fact that the server orders PdxType fields sequentially, rather than alphabetically. - In order to achieve what was originally intended with GEODE-8212, now PdxInstances fields are written in alphabetical order, rather than in the order writeXX is called. - Also, code now should be easier to understand - Several tests modified to adapt to code changes - Added several UTs to further incrase coverage on PDX (de)serialization code. - Added several ITs to verify PDX (de)serialization scenarios. > Refactor PDX (de)serialziation code to align it with Java client > > > Key: GEODE-10276 > URL: https://issues.apache.org/jira/browse/GEODE-10276 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > Currently there are the following open issues regarding PDX (de)serialization: > * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable > class|https://issues.apache.org/jira/browse/GEODE-9968] > * [GEODE-9753 - Coredump during PdxSerializable object > serialization|https://issues.apache.org/jira/browse/GEODE-9753] > * [GEODE-10220 - Coredump while initializing PdxType > remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220] > * [GEODE-10255 - PdxSerializable not working correctly for multiple versions > of the same class|https://issues.apache.org/jira/browse/GEODE-10255] > Also, the implementation on this ticket ([GEODE-8212: Reduce connections to > server to get type id|https://issues.apache.org/jira/browse/GEODE-8212]) > poses some issues with PDX entries which fields are a permutation. Thing is > that PdxTypes which fields are a permutation might use the wrong offsets, > leading to a corrupt serialization. This is something that was not taken into > account at the time of getting this PR merged. > So this ticket should be reverted and possibly an alternative solution > proposed. > In order to tackle these issues, a code refactoring is needed to introduce > the following implementations: > * Single type of PdxWriter > * An implementation PdxReader that tracks unread data, and other that don't. > * An implementation for PdxInstances that guarantees that fields are > actually written in alphabetical order, independently of the writeFields call > order. This should tackle the issue described above regarding GEODE-8212. > * Also, it'd be ideal to make it so PDX code is cleaner and easier to > understand, though that's a complex matter, and also, subjective. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-8546) Colocated regions missing some buckets after restart
[ https://issues.apache.org/jira/browse/GEODE-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-8546. --- Resolution: Fixed > Colocated regions missing some buckets after restart > > > Key: GEODE-8546 > URL: https://issues.apache.org/jira/browse/GEODE-8546 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.11.0, 1.12.0, 1.13.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > > After restart all servers at the same time, some colocation regions missing > some buckets. > This issue exist for a long time and become visible from 1.11.0 by > introducing this changes GEODE-7042 . > How to reproduce the issue: > # Start two locators and two servers > # Create PARTITION_REDUNDANT_PERSISTENT region with redundant-copies=1 > # Create few PARTITION_REDUNDANT regions(I used six regions) colocated with > persistent region and redundant-copies=1 > # Put some entries. > # Restart servers(you can simply run "kill -15 " and then from > two terminals start both of them at the same time) > # It will take a time to get server startup finished and for the latest > region bucketCount will be lower than expected on one member -- This message was sent by Atlassian Jira (v8.20.7#820007)
