[jira] [Resolved] (GEODE-9447) fix release scripts
[ https://issues.apache.org/jira/browse/GEODE-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-9447. - Fix Version/s: 1.15.0 Resolution: Fixed > fix release scripts > --- > > Key: GEODE-9447 > URL: https://issues.apache.org/jira/browse/GEODE-9447 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > * JAVA_HOME not respected in all cases > * rc pipeline did not get upthewaterspout tests from the correct repo > * one job in rc pipeline could run on old native or geode tag -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9447) fix release scripts
[ https://issues.apache.org/jira/browse/GEODE-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387666#comment-17387666 ] ASF subversion and git services commented on GEODE-9447: Commit 7e246f55aeea66c1209d1ce11517accc3dc8fa02 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e246f5 ] GEODE-9447: fix release scripts (#6712) * get upthewaterspout from the right repo * ensure native build from src tgz uses latest geode AND native bits * consider JAVA_HOME during initial environment checks * check that docker daemon is running before getting started > fix release scripts > --- > > Key: GEODE-9447 > URL: https://issues.apache.org/jira/browse/GEODE-9447 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > * JAVA_HOME not respected in all cases > * rc pipeline did not get upthewaterspout tests from the correct repo > * one job in rc pipeline could run on old native or geode tag -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-8200) Rebalance operations stuck in "IN_PROGRESS" state forever
[
https://issues.apache.org/jira/browse/GEODE-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387644#comment-17387644
]
Aaron Lindsey edited comment on GEODE-8200 at 7/26/21, 11:01 PM:
-
[~agingade] We first saw this issue on July 16 while testing Geode at commit
[https://github.com/apache/geode/commit/8b7a1a242290523310080a13338c1f85a283c684].
The issue was discovered in an automated test which had been passing
consistently for some time. We have only seen the issue happen with the
"restore redundancy" operation, but I cannot say for sure that the issue does
not happen for the "rebalance" operation as well.
We have a closed-source test which reproduces the issue, but it does not
reproduce the issue every time. The test does a rolling restart of the Geode
cluster by restarting up to one locator and one server at a time. We have a
Kubernetes hook which runs "restore redundancy" right before a server is
stopped to reduce the chance of data loss. The hook is implemented such that
the "restore redundancy" operation must succeed before the server can be
stopped. Note that this is the exact same scenario as described in the original
ticket description, except that we now use "restore redundancy" instead of
"rebalance".
was (Author: aaronlindsey):
[~agingade] We first saw this issue on July 16 while testing Geode at commit
[https://github.com/apache/geode/commit/8b7a1a242290523310080a13338c1f85a283c684.]
The issue was discovered in an automated test which had been passing
consistently for some time. We have only seen the issue happen with the
"restore redundancy" operation, but I cannot say for sure that the issue does
not happen for the "rebalance" operation as well.
We have a closed-source test which reproduces the issue, but it does not
reproduce the issue every time. The test does a rolling restart of the Geode
cluster by restarting up to one locator and one server at a time. We have a
Kubernetes hook which runs "restore redundancy" right before a server is
stopped to reduce the chance of data loss. The hook is implemented such that
the "restore redundancy" operation must succeed before the server can be
stopped. Note that this is the exact same scenario as described in the original
ticket description, except that we now use "restore redundancy" instead of
"rebalance".
> Rebalance operations stuck in "IN_PROGRESS" state forever
> -
>
> Key: GEODE-8200
> URL: https://issues.apache.org/jira/browse/GEODE-8200
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0
> Fix For: 1.13.1, 1.14.0
>
> Attachments: GEODE-8200-exportedLogs.zip
>
>
> We use the management REST API to call rebalance immediately before stopping
> a server to limit the possibility of data loss. In a cluster with 3 locators,
> 3 servers, and no regions, we noticed that sometimes the rebalance operation
> never ends if one of the locators is restarting concurrently with the
> rebalance operation.
> More specifically, the scenario where we see this issue crop up is during an
> automated "rolling restart" operation in a Kubernetes environment which
> proceeds as follows:
> * At most one locator and one server are restarting at any point in time
> * Each locator/server waits until the previous locator/server is fully online
> before restarting
> * Immediately before stopping a server, a rebalance operation is performed
> and the server is not stopped until the rebalance operation is completed
> The impact of this issue is that the "rolling restart" operation will never
> complete, because it cannot proceed with stopping a server until the
> rebalance operation is completed. A human is then required to intervene and
> manually trigger a rebalance and stop the server. This type of "rolling
> restart" operation is triggered fairly often in Kubernetes — any time part of
> the configuration of the locators or servers changes.
> The following JSON is a sample response from the management REST API that
> shows the rebalance operation stuck in "IN_PROGRESS".
> {code}
> {
> "statusCode": "IN_PROGRESS",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/a47f23c8-02b3-443c-a367-636fd6921ea7;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-05-27T22:38:30.619Z",
> "operationId": "a47f23c8-02b3-443c-a367-636fd6921ea7",
> "operation": {
> "simulate": false
> }
> }
> {code}
--
This message was sent by Atlassian
[jira] [Commented] (GEODE-8200) Rebalance operations stuck in "IN_PROGRESS" state forever
[
https://issues.apache.org/jira/browse/GEODE-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387644#comment-17387644
]
Aaron Lindsey commented on GEODE-8200:
--
[~agingade] We first saw this issue on July 16 while testing Geode at commit
[https://github.com/apache/geode/commit/8b7a1a242290523310080a13338c1f85a283c684.]
The issue was discovered in an automated test which had been passing
consistently for some time. We have only seen the issue happen with the
"restore redundancy" operation, but I cannot say for sure that the issue does
not happen for the "rebalance" operation as well.
We have a closed-source test which reproduces the issue, but it does not
reproduce the issue every time. The test does a rolling restart of the Geode
cluster by restarting up to one locator and one server at a time. We have a
Kubernetes hook which runs "restore redundancy" right before a server is
stopped to reduce the chance of data loss. The hook is implemented such that
the "restore redundancy" operation must succeed before the server can be
stopped. Note that this is the exact same scenario as described in the original
ticket description, except that we now use "restore redundancy" instead of
"rebalance".
> Rebalance operations stuck in "IN_PROGRESS" state forever
> -
>
> Key: GEODE-8200
> URL: https://issues.apache.org/jira/browse/GEODE-8200
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0
> Fix For: 1.13.1, 1.14.0
>
> Attachments: GEODE-8200-exportedLogs.zip
>
>
> We use the management REST API to call rebalance immediately before stopping
> a server to limit the possibility of data loss. In a cluster with 3 locators,
> 3 servers, and no regions, we noticed that sometimes the rebalance operation
> never ends if one of the locators is restarting concurrently with the
> rebalance operation.
> More specifically, the scenario where we see this issue crop up is during an
> automated "rolling restart" operation in a Kubernetes environment which
> proceeds as follows:
> * At most one locator and one server are restarting at any point in time
> * Each locator/server waits until the previous locator/server is fully online
> before restarting
> * Immediately before stopping a server, a rebalance operation is performed
> and the server is not stopped until the rebalance operation is completed
> The impact of this issue is that the "rolling restart" operation will never
> complete, because it cannot proceed with stopping a server until the
> rebalance operation is completed. A human is then required to intervene and
> manually trigger a rebalance and stop the server. This type of "rolling
> restart" operation is triggered fairly often in Kubernetes — any time part of
> the configuration of the locators or servers changes.
> The following JSON is a sample response from the management REST API that
> shows the rebalance operation stuck in "IN_PROGRESS".
> {code}
> {
> "statusCode": "IN_PROGRESS",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/a47f23c8-02b3-443c-a367-636fd6921ea7;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-05-27T22:38:30.619Z",
> "operationId": "a47f23c8-02b3-443c-a367-636fd6921ea7",
> "operation": {
> "simulate": false
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8200) Rebalance operations stuck in "IN_PROGRESS" state forever
[
https://issues.apache.org/jira/browse/GEODE-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-8200:
-
Labels: GeodeOperationAPI blocks-1.15.0 (was: GeodeOperationAPI)
> Rebalance operations stuck in "IN_PROGRESS" state forever
> -
>
> Key: GEODE-8200
> URL: https://issues.apache.org/jira/browse/GEODE-8200
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0
> Fix For: 1.13.1, 1.14.0
>
> Attachments: GEODE-8200-exportedLogs.zip
>
>
> We use the management REST API to call rebalance immediately before stopping
> a server to limit the possibility of data loss. In a cluster with 3 locators,
> 3 servers, and no regions, we noticed that sometimes the rebalance operation
> never ends if one of the locators is restarting concurrently with the
> rebalance operation.
> More specifically, the scenario where we see this issue crop up is during an
> automated "rolling restart" operation in a Kubernetes environment which
> proceeds as follows:
> * At most one locator and one server are restarting at any point in time
> * Each locator/server waits until the previous locator/server is fully online
> before restarting
> * Immediately before stopping a server, a rebalance operation is performed
> and the server is not stopped until the rebalance operation is completed
> The impact of this issue is that the "rolling restart" operation will never
> complete, because it cannot proceed with stopping a server until the
> rebalance operation is completed. A human is then required to intervene and
> manually trigger a rebalance and stop the server. This type of "rolling
> restart" operation is triggered fairly often in Kubernetes — any time part of
> the configuration of the locators or servers changes.
> The following JSON is a sample response from the management REST API that
> shows the rebalance operation stuck in "IN_PROGRESS".
> {code}
> {
> "statusCode": "IN_PROGRESS",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/a47f23c8-02b3-443c-a367-636fd6921ea7;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-05-27T22:38:30.619Z",
> "operationId": "a47f23c8-02b3-443c-a367-636fd6921ea7",
> "operation": {
> "simulate": false
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-9463:
Assignee: Eric Shu
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Aaron Lindsey
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.13.4, blocks-1.14.0
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster. I attached logs from 2 separate test
> failures due to this issue.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)at
>
[jira] [Commented] (GEODE-8200) Rebalance operations stuck in "IN_PROGRESS" state forever
[
https://issues.apache.org/jira/browse/GEODE-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387638#comment-17387638
]
Anilkumar Gingade commented on GEODE-8200:
--
>> Re-opened because this issue has started reproducing again on develop.
[~aaronlindsey] Can you please add more details to this...Reading this ticket
description, the issue was addressed with "Rebalance"; from your comments it
seems like its with :restore redundancy" command...
Questions:
- Is the issue with the "rebalance" command?
- Is the issue only with "restore redundancy"?
- Is there a test that reproduces the issue?
- What are the steps involved in reproducing the issue? Does the issue
reproduces every time?
> Rebalance operations stuck in "IN_PROGRESS" state forever
> -
>
> Key: GEODE-8200
> URL: https://issues.apache.org/jira/browse/GEODE-8200
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI
> Fix For: 1.13.1, 1.14.0
>
> Attachments: GEODE-8200-exportedLogs.zip
>
>
> We use the management REST API to call rebalance immediately before stopping
> a server to limit the possibility of data loss. In a cluster with 3 locators,
> 3 servers, and no regions, we noticed that sometimes the rebalance operation
> never ends if one of the locators is restarting concurrently with the
> rebalance operation.
> More specifically, the scenario where we see this issue crop up is during an
> automated "rolling restart" operation in a Kubernetes environment which
> proceeds as follows:
> * At most one locator and one server are restarting at any point in time
> * Each locator/server waits until the previous locator/server is fully online
> before restarting
> * Immediately before stopping a server, a rebalance operation is performed
> and the server is not stopped until the rebalance operation is completed
> The impact of this issue is that the "rolling restart" operation will never
> complete, because it cannot proceed with stopping a server until the
> rebalance operation is completed. A human is then required to intervene and
> manually trigger a rebalance and stop the server. This type of "rolling
> restart" operation is triggered fairly often in Kubernetes — any time part of
> the configuration of the locators or servers changes.
> The following JSON is a sample response from the management REST API that
> shows the rebalance operation stuck in "IN_PROGRESS".
> {code}
> {
> "statusCode": "IN_PROGRESS",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/a47f23c8-02b3-443c-a367-636fd6921ea7;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-05-27T22:38:30.619Z",
> "operationId": "a47f23c8-02b3-443c-a367-636fd6921ea7",
> "operation": {
> "simulate": false
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9463:
Labels: GeodeOperationAPI blocks-1.13.4 blocks-1.14.0 (was:
GeodeOperationAPI blocks-1.13.4 blocks-1.13.5 blocks-1.14.0)
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Aaron Lindsey
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.13.4, blocks-1.14.0
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster. I attached logs from 2 separate test
> failures due to this issue.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)
[jira] [Updated] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9463:
Labels: GeodeOperationAPI blocks-1.13.4 blocks-1.13.5 blocks-1.14.0 (was:
GeodeOperationAPI blocks-1.13.5 blocks-1.14.0)
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Aaron Lindsey
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.13.4, blocks-1.13.5,
> blocks-1.14.0
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster. I attached logs from 2 separate test
> failures due to this issue.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
> at
>
[jira] [Updated] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9463:
Labels: GeodeOperationAPI blocks-1.13.5 blocks-1.14.0 (was:
GeodeOperationAPI blocks-1.14.0)
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Aaron Lindsey
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.13.5, blocks-1.14.0
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster. I attached logs from 2 separate test
> failures due to this issue.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)at
>
[jira] [Updated] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9463:
-
Labels: GeodeOperationAPI blocks-1.14.0 (was: blocks-1.14.0)
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Aaron Lindsey
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.14.0
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster. I attached logs from 2 separate test
> failures due to this issue.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)at
>
[jira] [Updated] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9463:
-
Labels: blocks-1.14.0 (was: )
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Aaron Lindsey
>Priority: Major
> Labels: blocks-1.14.0
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster. I attached logs from 2 separate test
> failures due to this issue.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:86)at
>
[jira] [Updated] (GEODE-9464) Add a non-Steeltoe Asp.Net Core SessionState sample app to SessionStateCore
[ https://issues.apache.org/jira/browse/GEODE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Martell updated GEODE-9464: --- Description: The current Asp.Net sample app uses Steeltoe for discovery and registration of our sessionstate provider. We need a non-Steeltoe sample as well, since not everyone uses Steeltoe. This will be a good test of our NuGet access to the SessionState Core artifacts and its dependencies. Note: Ensure that the web application runs on all platforms. was: The current Asp.Net sample app uses Steeltoe for discovery and registration of our sessionstate provider. We need a non-Steeltoe sample as well, since not everyone uses Steeltoe. This will be a good test of our NuGet access to the SessionState Core artifacts and its dependencies. Summary: Add a non-Steeltoe Asp.Net Core SessionState sample app to SessionStateCore (was: Add a non-Steeltoe Asp.Net Core SessionState sample app) > Add a non-Steeltoe Asp.Net Core SessionState sample app to SessionStateCore > --- > > Key: GEODE-9464 > URL: https://issues.apache.org/jira/browse/GEODE-9464 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > > The current Asp.Net sample app uses Steeltoe for discovery and registration > of our sessionstate provider. We need a non-Steeltoe sample as well, since > not everyone uses Steeltoe. > This will be a good test of our NuGet access to the SessionState Core > artifacts and its dependencies. > Note: Ensure that the web application runs on all platforms. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9464) Add a non-Steeltoe Asp.Net Core SessionState sample app
Michael Martell created GEODE-9464: -- Summary: Add a non-Steeltoe Asp.Net Core SessionState sample app Key: GEODE-9464 URL: https://issues.apache.org/jira/browse/GEODE-9464 Project: Geode Issue Type: Test Components: native client Reporter: Michael Martell The current Asp.Net sample app uses Steeltoe for discovery and registration of our sessionstate provider. We need a non-Steeltoe sample as well, since not everyone uses Steeltoe. This will be a good test of our NuGet access to the SessionState Core artifacts and its dependencies. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387598#comment-17387598
]
Kirk Lund commented on GEODE-9463:
--
This bug is in 1.14.x and might also be in 1.13.x.
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Aaron Lindsey
>Priority: Major
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster. I attached logs from 2 separate test
> failures due to this issue.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:86)at
>
[jira] [Resolved] (GEODE-7395) Add Micrometer to documentation
[ https://issues.apache.org/jira/browse/GEODE-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-7395. Resolution: Fixed Cleanup. Fixed in v1.11 back in 2019. > Add Micrometer to documentation > --- > > Key: GEODE-7395 > URL: https://issues.apache.org/jira/browse/GEODE-7395 > Project: Geode > Issue Type: Improvement > Components: docs, statistics >Reporter: Nick Vallely >Assignee: Dave Barnes >Priority: Major > Labels: observability > Fix For: 1.11.0 > > Time Spent: 3h > Remaining Estimate: 0h > > As of 1.9 we added Micrometer as a way to publish metrics to external > monitoring systems. As of 1.10/1.11 we added metrics that would be emitted > out of a Meter Registry and documented everything in the Apache Geode wiki. > We need to formalize some of this functionality a little more with a section > on Micrometer in our docx. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7395) Add Micrometer to documentation
[ https://issues.apache.org/jira/browse/GEODE-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes closed GEODE-7395. -- > Add Micrometer to documentation > --- > > Key: GEODE-7395 > URL: https://issues.apache.org/jira/browse/GEODE-7395 > Project: Geode > Issue Type: Improvement > Components: docs, statistics >Reporter: Nick Vallely >Assignee: Dave Barnes >Priority: Major > Labels: observability > Fix For: 1.11.0 > > Time Spent: 3h > Remaining Estimate: 0h > > As of 1.9 we added Micrometer as a way to publish metrics to external > monitoring systems. As of 1.10/1.11 we added metrics that would be emitted > out of a Meter Registry and documented everything in the Apache Geode wiki. > We need to formalize some of this functionality a little more with a section > on Micrometer in our docx. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-9463:
-
Description:
When validate-serializable-objects=true, there are exceptions in the logs
related to serializing the class SerializableRegionRedundancyStatusImpl. This
is an internal class which should be allowed by the default serializable object
filter.
We saw this issue happen on Kubernetes while invoking rebalance and restore
redundancy operations on the cluster. I attached logs from 2 separate test
failures due to this issue.
{code:java}
[fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
tid=0x51] Serialization filter is rejecting class
org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
at
org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
at
java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
at
java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
at
java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
at
java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
at
org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
at
org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
at
org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
at
org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
at
org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
at
org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
at org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)
at org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:86)
at
org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:187)
at
org.apache.geode.internal.cache.EntriesSet$EntriesIterator.(EntriesSet.java:119)
at org.apache.geode.internal.cache.EntriesSet.iterator(EntriesSet.java:84)
at
org.apache.geode.management.internal.operation.RegionOperationStateStore.list(RegionOperationStateStore.java:102)
at
org.apache.geode.management.internal.operation.OperationHistoryManager.expireHistory(OperationHistoryManager.java:74)
at
org.apache.geode.management.internal.operation.OperationHistoryManager.recordStart(OperationHistoryManager.java:120)
at
[jira] [Comment Edited] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387554#comment-17387554
]
Darrel Schneider edited comment on GEODE-9393 at 7/26/21, 7:09 PM:
---
It looks like all of the issues found so far involve geode making calls to
Field.setAccessible. It looks like Method.setAccessible would also be an issue.
For more info on why this started failing see:
[https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
was (Author: dschneider):
It looks like all of the issues found so far involve geode making calls to
Field.setAccessible. For more info on why this started failing see:
https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m
> Apache Geode does not run on Java 16
>
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO
[jira] [Updated] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-9463:
-
Attachment: logs-2.tgz
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Aaron Lindsey
>Priority: Major
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:86)at
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:187)
> at
>
[jira] [Updated] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-9463:
-
Attachment: logs-1.tgz
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Aaron Lindsey
>Priority: Major
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
> at
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
> at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)at
> org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:86)at
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:187)
> at
>
[jira] [Commented] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387554#comment-17387554
]
Darrel Schneider commented on GEODE-9393:
-
It looks like all of the issues found so far involve geode making calls to
Field.setAccessible. For more info on why this started failing see:
https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m
> Apache Geode does not run on Java 16
>
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared
[jira] [Created] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
Aaron Lindsey created GEODE-9463:
Summary: Default serialization filter rejects
SerializableRegionRedundancyStatusImpl
Key: GEODE-9463
URL: https://issues.apache.org/jira/browse/GEODE-9463
Project: Geode
Issue Type: Bug
Components: serialization
Reporter: Aaron Lindsey
When validate-serializable-objects=true, there are exceptions in the logs
related to serializing the class SerializableRegionRedundancyStatusImpl. This
is an internal class which should be allowed by the default serializable object
filter.
We saw this issue happen on Kubernetes while invoking rebalance and restore
redundancy operations on the cluster.
{code:java}
[fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
tid=0x51] Serialization filter is rejecting class
org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
at
org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
at
java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
at
java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
at java.base/java.util.HashMap.readObject(HashMap.java:1460)at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
at
java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
at
java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
at
java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
at
org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2689)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2633)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
at
org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
at
org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2049)
at
org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2041)
at
org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:138)
at
org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1277)
at org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:91)
at org.apache.geode.internal.cache.NonTXEntry.getValue(NonTXEntry.java:86)
at
org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:187)
at
org.apache.geode.internal.cache.EntriesSet$EntriesIterator.(EntriesSet.java:119)
at org.apache.geode.internal.cache.EntriesSet.iterator(EntriesSet.java:84)
at
org.apache.geode.management.internal.operation.RegionOperationStateStore.list(RegionOperationStateStore.java:102)
at
org.apache.geode.management.internal.operation.OperationHistoryManager.expireHistory(OperationHistoryManager.java:74)
at
[jira] [Reopened] (GEODE-9428) CI Failure: PSetEXNativeRedisAcceptanceTest fails with CLUSTERDOWN error
[
https://issues.apache.org/jira/browse/GEODE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wayne reopened GEODE-9428:
--
Assignee: (was: Hale Bales)
Reopening because we are seeing this exception again.
> CI Failure: PSetEXNativeRedisAcceptanceTest fails with CLUSTERDOWN error
>
>
> Key: GEODE-9428
> URL: https://issues.apache.org/jira/browse/GEODE-9428
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Hale Bales
>Priority: Major
>
> CI run is here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/82#L60e11384:311
> {code:java}
> org.apache.geode.redis.internal.executor.string.PSetEXNativeRedisAcceptanceTest
> > testPSetEX FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.Jedis.psetex(Jedis.java:3616)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:572)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:569)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.psetex(JedisCluster.java:574)
> at
> org.apache.geode.redis.internal.executor.string.AbstractPSetEXIntegrationTest.testPSetEX(AbstractPSetEXIntegrationTest.java:54)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 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.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:120)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>
[jira] [Updated] (GEODE-9462) Dump call stacks from both Dockerized and non-Dockerized java processes
[
https://issues.apache.org/jira/browse/GEODE-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9462:
--
Labels: pull-request-available (was: )
> Dump call stacks from both Dockerized and non-Dockerized java processes
> ---
>
> Key: GEODE-9462
> URL: https://issues.apache.org/jira/browse/GEODE-9462
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available
>
> Currently, {{ci/scripts/capture-call-stacks.sh}} assumes that if
> {{PARALLEL_DUNIT}} is empty, tests were run in plain Java processes, and if
> it is non-empty, tests were run in Docker containers.
> GEODE-8728 violates that assumption: It runs parallel tests in plain Java
> processes, without Docker containers.
> Currently, the script looks in different places for Java processes, depending
> on whether {{PARALLEL_DUNIT}} is empty. If it is empty, the script dumps
> stacks from plain Java processes on the machine, and only those processes. If
> it is non-empty, the script dumps stacks from Java processes running inside
> Docker containers, and only those processes.
> This will not work in builds that include GEODE-8728.
> To allow the script to work both for newer builds that include GEODE-8728 and
> older builds that do not, change it to dump call stacks from both places,
> regardless of whether `PARALLEL_DUNIT` is empty. If `jps` reports any
> processes, dump their stacks. And if `docker ps` reports any containers, dump
> the stacks of the Java processes in each container.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9462) Dump call stacks from both Dockerized and non-Dockerized java processes
[
https://issues.apache.org/jira/browse/GEODE-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9462:
--
Labels: GeodeOperationAPI (was: pull-request-available)
> Dump call stacks from both Dockerized and non-Dockerized java processes
> ---
>
> Key: GEODE-9462
> URL: https://issues.apache.org/jira/browse/GEODE-9462
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> Currently, {{ci/scripts/capture-call-stacks.sh}} assumes that if
> {{PARALLEL_DUNIT}} is empty, tests were run in plain Java processes, and if
> it is non-empty, tests were run in Docker containers.
> GEODE-8728 violates that assumption: It runs parallel tests in plain Java
> processes, without Docker containers.
> Currently, the script looks in different places for Java processes, depending
> on whether {{PARALLEL_DUNIT}} is empty. If it is empty, the script dumps
> stacks from plain Java processes on the machine, and only those processes. If
> it is non-empty, the script dumps stacks from Java processes running inside
> Docker containers, and only those processes.
> This will not work in builds that include GEODE-8728.
> To allow the script to work both for newer builds that include GEODE-8728 and
> older builds that do not, change it to dump call stacks from both places,
> regardless of whether `PARALLEL_DUNIT` is empty. If `jps` reports any
> processes, dump their stacks. And if `docker ps` reports any containers, dump
> the stacks of the Java processes in each container.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9462) Dump call stacks from both Dockerized and non-Dockerized java processes
[
https://issues.apache.org/jira/browse/GEODE-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-9462:
-
Assignee: Dale Emery
> Dump call stacks from both Dockerized and non-Dockerized java processes
> ---
>
> Key: GEODE-9462
> URL: https://issues.apache.org/jira/browse/GEODE-9462
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>
> Currently, {{ci/scripts/capture-call-stacks.sh}} assumes that if
> {{PARALLEL_DUNIT}} is empty, tests were run in plain Java processes, and if
> it is non-empty, tests were run in Docker containers.
> GEODE-8728 violates that assumption: It runs parallel tests in plain Java
> processes, without Docker containers.
> Currently, the script looks in different places for Java processes, depending
> on whether {{PARALLEL_DUNIT}} is empty. If it is empty, the script dumps
> stacks from plain Java processes on the machine, and only those processes. If
> it is non-empty, the script dumps stacks from Java processes running inside
> Docker containers, and only those processes.
> This will not work in builds that include GEODE-8728.
> To allow the script to work both for newer builds that include GEODE-8728 and
> older builds that do not, change it to dump call stacks from both places,
> regardless of whether `PARALLEL_DUNIT` is empty. If `jps` reports any
> processes, dump their stacks. And if `docker ps` reports any containers, dump
> the stacks of the Java processes in each container.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9462) Dump call stacks from both Dockerized and non-Dockerized java processes
Dale Emery created GEODE-9462:
-
Summary: Dump call stacks from both Dockerized and non-Dockerized
java processes
Key: GEODE-9462
URL: https://issues.apache.org/jira/browse/GEODE-9462
Project: Geode
Issue Type: Improvement
Components: build
Reporter: Dale Emery
Currently, {{ci/scripts/capture-call-stacks.sh}} assumes that if
{{PARALLEL_DUNIT}} is empty, tests were run in plain Java processes, and if it
is non-empty, tests were run in Docker containers.
GEODE-8728 violates that assumption: It runs parallel tests in plain Java
processes, without Docker containers.
Currently, the script looks in different places for Java processes, depending
on whether {{PARALLEL_DUNIT}} is empty. If it is empty, the script dumps stacks
from plain Java processes on the machine, and only those processes. If it is
non-empty, the script dumps stacks from Java processes running inside Docker
containers, and only those processes.
This will not work in builds that include GEODE-8728.
To allow the script to work both for newer builds that include GEODE-8728 and
older builds that do not, change it to dump call stacks from both places,
regardless of whether `PARALLEL_DUNIT` is empty. If `jps` reports any
processes, dump their stacks. And if `docker ps` reports any containers, dump
the stacks of the Java processes in each container.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9428) CI Failure: PSetEXNativeRedisAcceptanceTest fails with CLUSTERDOWN error
[
https://issues.apache.org/jira/browse/GEODE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387531#comment-17387531
]
Geode Integration commented on GEODE-9428:
--
Seen in [acceptance-test-openjdk11
#96|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/96]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0381/test-results/acceptanceTest/1627082553/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0381/test-artifacts/1627082553/acceptancetestfiles-openjdk11-1.15.0-build.0381.tgz].
> CI Failure: PSetEXNativeRedisAcceptanceTest fails with CLUSTERDOWN error
>
>
> Key: GEODE-9428
> URL: https://issues.apache.org/jira/browse/GEODE-9428
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Hale Bales
>Assignee: Hale Bales
>Priority: Major
>
> CI run is here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/82#L60e11384:311
> {code:java}
> org.apache.geode.redis.internal.executor.string.PSetEXNativeRedisAcceptanceTest
> > testPSetEX FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.Jedis.psetex(Jedis.java:3616)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:572)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:569)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.psetex(JedisCluster.java:574)
> at
> org.apache.geode.redis.internal.executor.string.AbstractPSetEXIntegrationTest.testPSetEX(AbstractPSetEXIntegrationTest.java:54)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 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.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:120)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
>
[jira] [Comment Edited] (GEODE-9428) CI Failure: PSetEXNativeRedisAcceptanceTest fails with CLUSTERDOWN error
[
https://issues.apache.org/jira/browse/GEODE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387526#comment-17387526
]
Nabarun Nag edited comment on GEODE-9428 at 7/26/21, 6:22 PM:
--
https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11074947
{noformat}
org.apache.geode.redis.internal.executor.string.IncrNativeRedisAcceptanceTest >
testIncr FAILED
redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
cluster is down
at redis.clients.jedis.Protocol.processError(Protocol.java:125)
at redis.clients.jedis.Protocol.process(Protocol.java:169)
at redis.clients.jedis.Protocol.read(Protocol.java:223)
at
redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
at
redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
at redis.clients.jedis.Jedis.set(Jedis.java:225)
at redis.clients.jedis.JedisCluster$2.execute(JedisCluster.java:291)
at redis.clients.jedis.JedisCluster$2.execute(JedisCluster.java:288)
at
redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
at
redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
at redis.clients.jedis.JedisCluster.set(JedisCluster.java:293)
at
org.apache.geode.redis.internal.executor.string.AbstractIncrIntegrationTest.testIncr(AbstractIncrIntegrationTest.java:65)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
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.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:120)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
at
[jira] [Commented] (GEODE-9428) CI Failure: PSetEXNativeRedisAcceptanceTest fails with CLUSTERDOWN error
[
https://issues.apache.org/jira/browse/GEODE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387526#comment-17387526
]
Nabarun Nag commented on GEODE-9428:
{noformat}
org.apache.geode.redis.internal.executor.string.IncrNativeRedisAcceptanceTest >
testIncr FAILED
redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
cluster is down
at redis.clients.jedis.Protocol.processError(Protocol.java:125)
at redis.clients.jedis.Protocol.process(Protocol.java:169)
at redis.clients.jedis.Protocol.read(Protocol.java:223)
at
redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
at
redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
at redis.clients.jedis.Jedis.set(Jedis.java:225)
at redis.clients.jedis.JedisCluster$2.execute(JedisCluster.java:291)
at redis.clients.jedis.JedisCluster$2.execute(JedisCluster.java:288)
at
redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
at
redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
at redis.clients.jedis.JedisCluster.set(JedisCluster.java:293)
at
org.apache.geode.redis.internal.executor.string.AbstractIncrIntegrationTest.testIncr(AbstractIncrIntegrationTest.java:65)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
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.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:120)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
at
[jira] [Commented] (GEODE-7071) Add CA capability to CertStores
[ https://issues.apache.org/jira/browse/GEODE-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387523#comment-17387523 ] Geode Integration commented on GEODE-7071: -- Seen on support/1.13 in [acceptance-test-openjdk8 #35|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/acceptance-test-openjdk8/builds/35] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0570/test-results/acceptanceTest/1626862180/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0570/test-artifacts/1626862180/acceptancetestfiles-openjdk8-1.13.4-build.0570.tgz]. > Add CA capability to CertStores > --- > > Key: GEODE-7071 > URL: https://issues.apache.org/jira/browse/GEODE-7071 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Most (all?) SSL tests end up using self-signed certificates. We should add an > actual root CA so that certificates can actually be signed correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-9360) Initial revision of .net core support
[ https://issues.apache.org/jira/browse/GEODE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-9360. --- > Initial revision of .net core support > - > > Key: GEODE-9360 > URL: https://issues.apache.org/jira/browse/GEODE-9360 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > As a .net core developer, I would like to be able to access the geode-native > API. To facilitate this, we need to implement a minimal set of C# classes > that use p/invoke to access geode-native via C bindings (GEODE-9358). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9360) Initial revision of .net core support
[ https://issues.apache.org/jira/browse/GEODE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-9360. - Resolution: Fixed > Initial revision of .net core support > - > > Key: GEODE-9360 > URL: https://issues.apache.org/jira/browse/GEODE-9360 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > As a .net core developer, I would like to be able to access the geode-native > API. To facilitate this, we need to implement a minimal set of C# classes > that use p/invoke to access geode-native via C bindings (GEODE-9358). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9360) Initial revision of .net core support
[ https://issues.apache.org/jira/browse/GEODE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt reassigned GEODE-9360: --- Assignee: Blake Bender > Initial revision of .net core support > - > > Key: GEODE-9360 > URL: https://issues.apache.org/jira/browse/GEODE-9360 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > As a .net core developer, I would like to be able to access the geode-native > API. To facilitate this, we need to implement a minimal set of C# classes > that use p/invoke to access geode-native via C bindings (GEODE-9358). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387510#comment-17387510
]
Darrel Schneider commented on GEODE-9393:
-
The BufferPool failure may have been addressed by:
https://issues.apache.org/jira/browse/GEODE-9081 or it will cause it to fail in
a different way. This fix is currently only in geode 1.15
> Apache Geode does not run on Java 16
>
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared unordered uid=1 local port=53039 remote port=64063,10,main]
> -
[jira] [Resolved] (GEODE-8405) Native Client asks for metadata for replicated region, causes server exception
[
https://issues.apache.org/jira/browse/GEODE-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt resolved GEODE-8405.
-
Resolution: Fixed
> Native Client asks for metadata for replicated region, causes server exception
> --
>
> Key: GEODE-8405
> URL: https://issues.apache.org/jira/browse/GEODE-8405
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> For some reason, Geode Native is not checking region attributes on the server
> prior to issuing a GET_CLIENT_PR_METADATA message. It does, in fact, get the
> region attributes from the server, as you can see from this message dump:
> {code:java}
> {
> "Timestamp": "2020-08-05 15:37:42.595294",
> "Connection": "0x7fb1f89042d0",
> "Direction": "--->",
> "Type": "GET_CLIENT_PARTITION_ATTRIBUTES",
> "Length": 22,
> "Parts": 1,
> "TransactionId": -1,
> "SecurityFlag": 0,
> "RegionPart": {
> "Size": 17,
> "IsObject": 0,
> "Name": "/example_userinfo"
> }
> }
> ,{
> "Timestamp": "15:37:42.595590",
> "Connection": "0",
> "Direction": "<---",
> "Type": "RESPONSE_CLIENT_PARTITION_ATTRIBUTES",
> "Length": 35,
> "Parts": 2,
> "TransactionId": -1,
> "SecurityFlag": 0,
> "BucketCount": {
> "Size": 5,
> "IsObject": 1,
> "Data":{
> "DSCode": "CacheableInt32",
> "Value": -1
> }
> },
> "ColocatedWith": {
> "Size": 20,
> "IsObject": 1,
> "Data":{
> "DSCode": "CacheableASCIIString",
> "StringLength": 17,
> "Value": "/example_userinfo"
> }
> }
> }
> {code}
>
> The critical value here is `BucketCount` in the
> `RESPONSE_CLIENT_PARTITION_ATTRIBUTES` message. If this value is -1, the
> region is replicated rather than partitioned, and we should not be querying
> for PR metadata.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8405) Native Client asks for metadata for replicated region, causes server exception
[
https://issues.apache.org/jira/browse/GEODE-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-8405.
---
> Native Client asks for metadata for replicated region, causes server exception
> --
>
> Key: GEODE-8405
> URL: https://issues.apache.org/jira/browse/GEODE-8405
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> For some reason, Geode Native is not checking region attributes on the server
> prior to issuing a GET_CLIENT_PR_METADATA message. It does, in fact, get the
> region attributes from the server, as you can see from this message dump:
> {code:java}
> {
> "Timestamp": "2020-08-05 15:37:42.595294",
> "Connection": "0x7fb1f89042d0",
> "Direction": "--->",
> "Type": "GET_CLIENT_PARTITION_ATTRIBUTES",
> "Length": 22,
> "Parts": 1,
> "TransactionId": -1,
> "SecurityFlag": 0,
> "RegionPart": {
> "Size": 17,
> "IsObject": 0,
> "Name": "/example_userinfo"
> }
> }
> ,{
> "Timestamp": "15:37:42.595590",
> "Connection": "0",
> "Direction": "<---",
> "Type": "RESPONSE_CLIENT_PARTITION_ATTRIBUTES",
> "Length": 35,
> "Parts": 2,
> "TransactionId": -1,
> "SecurityFlag": 0,
> "BucketCount": {
> "Size": 5,
> "IsObject": 1,
> "Data":{
> "DSCode": "CacheableInt32",
> "Value": -1
> }
> },
> "ColocatedWith": {
> "Size": 20,
> "IsObject": 1,
> "Data":{
> "DSCode": "CacheableASCIIString",
> "StringLength": 17,
> "Value": "/example_userinfo"
> }
> }
> }
> {code}
>
> The critical value here is `BucketCount` in the
> `RESPONSE_CLIENT_PARTITION_ATTRIBUTES` message. If this value is -1, the
> region is replicated rather than partitioned, and we should not be querying
> for PR metadata.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-9401) Fix Duplicate Defines on OSX
[ https://issues.apache.org/jira/browse/GEODE-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-9401. --- > Fix Duplicate Defines on OSX > > > Key: GEODE-9401 > URL: https://issues.apache.org/jira/browse/GEODE-9401 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > Recent changes to system headers causes compile errors on OSX due to > redefinition of: > * BYTE_SIZE > * PAGE_SIZE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9429) Radish HSCAN implementation cannot handle values for COUNT greater than Integer.MAX_VALUE / 2
[
https://issues.apache.org/jira/browse/GEODE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387481#comment-17387481
]
ASF subversion and git services commented on GEODE-9429:
Commit 7d08ab52133183b767c1d1e7d57d44a65cfe32d5 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7d08ab5 ]
GEODE-9429: Allow Radish HSCAN to handle all valid values for COUNT (#6701)
- Refactor RedisHash.hscan() to handle large COUNT values
- Return suitable error message to user if HSCAN COUNT argument would
cause an OutOfMemoryError
- Add tests to cover new behaviour
- Refactor and clean up AbstractHScanIntegrationTest
Authored-by: Donal Evans
> Radish HSCAN implementation cannot handle values for COUNT greater than
> Integer.MAX_VALUE / 2
> -
>
> Key: GEODE-9429
> URL: https://issues.apache.org/jira/browse/GEODE-9429
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> The below code is the current implementation of HSCAN in {{RedisHash}}. When
> the value of {{count}} passed to this method is greater than
> {{Integer.MAX_VALUE / 2}} the condition of the while loop suffers from
> integer overflow and the loop does not execute correctly.
> {code:java}
> public ImmutablePair> hscan(Pattern matchPattern, int
> count, int cursor) {
> ArrayList resultList = new ArrayList<>(count + 2);
> do {
> cursor = hash.scan(cursor, 1,
> (list, key, value) -> addIfMatching(matchPattern, list, key,
> value), resultList);
> } while (cursor != 0 && resultList.size() < (count * 2));
> return new ImmutablePair<>(cursor, resultList);
> {code}
> This could be fixed by changing the type of {{resultList}} to
> {{List>}} and modifying the {{addIfMatching()}}
> method to populate the list with {{ImmutablePair}}s of keys and values rather
> than a single continuous list of interleaved keys and values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9354) Refactor ArgumentRedactor and add tests for ssl-*store-password props
[
https://issues.apache.org/jira/browse/GEODE-9354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387480#comment-17387480
]
ASF subversion and git services commented on GEODE-9354:
Commit 693e18c48d1c0e3601c517cb7c5493b54649dc10 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=693e18c ]
GEODE-9354: Extract and test ArgumentRedactorRegex (#6641)
* Rename ArgumentRedactorJUnitTest to ArgumentRedactorTest.
* Reorganize and reformat ArgumentRedactor and its tests.
* Fix issues in regex found by new tests.
> Refactor ArgumentRedactor and add tests for ssl-*store-password props
> -
>
> Key: GEODE-9354
> URL: https://issues.apache.org/jira/browse/GEODE-9354
> Project: Geode
> Issue Type: Wish
> Components: logging
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Refactor ArgumentRedactor to clean it up and make sure it's efficient.
> Add test coverage for log statements containing:
> {noformat}
> -Dgemfire.ssl-truststore-password=
> -Dgemfire.ssl-keystore-password=
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9429) Radish HSCAN implementation cannot handle values for COUNT greater than Integer.MAX_VALUE / 2
[
https://issues.apache.org/jira/browse/GEODE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-9429.
Fix Version/s: 1.15.0
Resolution: Fixed
> Radish HSCAN implementation cannot handle values for COUNT greater than
> Integer.MAX_VALUE / 2
> -
>
> Key: GEODE-9429
> URL: https://issues.apache.org/jira/browse/GEODE-9429
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> The below code is the current implementation of HSCAN in {{RedisHash}}. When
> the value of {{count}} passed to this method is greater than
> {{Integer.MAX_VALUE / 2}} the condition of the while loop suffers from
> integer overflow and the loop does not execute correctly.
> {code:java}
> public ImmutablePair> hscan(Pattern matchPattern, int
> count, int cursor) {
> ArrayList resultList = new ArrayList<>(count + 2);
> do {
> cursor = hash.scan(cursor, 1,
> (list, key, value) -> addIfMatching(matchPattern, list, key,
> value), resultList);
> } while (cursor != 0 && resultList.size() < (count * 2));
> return new ImmutablePair<>(cursor, resultList);
> {code}
> This could be fixed by changing the type of {{resultList}} to
> {{List>}} and modifying the {{addIfMatching()}}
> method to populate the list with {{ImmutablePair}}s of keys and values rather
> than a single continuous list of interleaved keys and values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9446) Remove unnecessary uses of byte[] in RedisSortedSet
[
https://issues.apache.org/jira/browse/GEODE-9446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387473#comment-17387473
]
Dan Smith commented on GEODE-9446:
--
In addition, the Double (capital D) score should be changed to a lower case d.
> Remove unnecessary uses of byte[] in RedisSortedSet
> ---
>
> Key: GEODE-9446
> URL: https://issues.apache.org/jira/browse/GEODE-9446
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> The current implementation of {{RedisSortedSet}} uses an
> {{AbstractOrderedStatisticsEntry}} class containing both {{double}} score and
> {{byte[]}} scoreBytes fields. The {{double}} field is required to allow the
> sorting behaviour required of the data structure, but the {{byte[]}} field is
> not necessary except when returning results to the client.
> The class should be refactored to eliminate the {{byte[]}} scoreBytes field
> from {{AbstractOrderedStatisticsEntry}} and reduce the memory overhead of
> operations.
> As part of this refactoring, the below call to {{members.put()}} should be
> removed from {{memberAdd()}} as it will no longer be necessary.
> {code:java}
> protected synchronized byte[] memberAdd(byte[] memberToAdd, byte[]
> scoreToAdd) {
> ...
> } else {
> scoreSet.remove(existingEntry);
> byte[] oldScore = existingEntry.scoreBytes;
> existingEntry.updateScore(stripTrailingZeroFromDouble(scoreToAdd));
> members.put(memberToAdd, existingEntry); <<< remove this
> scoreSet.add(existingEntry);
> return oldScore;
> }
> {code}
> Also, uses of the {{stripTrailingZeroFromDouble()}} method should be moved to
> just prior to the response being returned to the client, to ensure that the
> format of the returned String representations of double values match native
> Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9461) Eliminate use of macros in CLI ExceptionTypes.hpp
Blake Bender created GEODE-9461:
---
Summary: Eliminate use of macros in CLI ExceptionTypes.hpp
Key: GEODE-9461
URL: https://issues.apache.org/jira/browse/GEODE-9461
Project: Geode
Issue Type: Improvement
Components: native client
Reporter: Blake Bender
This kind of thing is an anti-pattern, and needs to be stamped out of the code
base:
{code}
#define _GF_MG_EXCEPTION_TRY2\
try {
{code}
Other bad macros in this file include _GF_MG_EXCEPTION_CATCH_ALL2,
_GF_MG_EXCEPTION_DEF3, and _GF_MG_EXCEPTION_DEF4. The latter 2 should be
replaced (if possible) by one or two judicious template classes, or written out
longhand because even brute force is better than what we have. Where possible,
code for the various methods should be moved to an implementation file, rather
than left in the header. CLI code in headers has its own special brand of
problems, making it extremely difficult to modify.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9453) The server, once a user expires, should clean the user attributes from the server.
[ https://issues.apache.org/jira/browse/GEODE-9453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-9453: -- Labels: GeodeOperationAPI (was: ) > The server, once a user expires, should clean the user attributes from the > server. > -- > > Key: GEODE-9453 > URL: https://issues.apache.org/jira/browse/GEODE-9453 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > ClientUserAuths maintains a map of clientID to its user attributes (the > logged in shiro subject etc), when user expires, we need to remove that entry > from that map and log the shiro subject out to avoid resource leak. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9454) The client, if multiple operations are in flight, should not flood the authentication server with re-authentication requests.
[ https://issues.apache.org/jira/browse/GEODE-9454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-9454: -- Labels: GeodeOperationAPI (was: ) > The client, if multiple operations are in flight, should not flood the > authentication server with re-authentication requests. > - > > Key: GEODE-9454 > URL: https://issues.apache.org/jira/browse/GEODE-9454 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > the blocking should only be for one client only > Having a test with multiple clients with multiple thread doing cache > operations > The test should also cover the multi-user authentication mode -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9452) The older version client should receive the AuthenticationRequiredException when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-9452: -- Labels: GeodeOperationAPI (was: ) > The older version client should receive the AuthenticationRequiredException > when authentication expires > --- > > Key: GEODE-9452 > URL: https://issues.apache.org/jira/browse/GEODE-9452 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > Currently, for older client, it's receiving a ClassNotFoundException, we need > to add the serialization code to convert the AuthenticationExpiredException > into this old exception type that the older clients can understand. > > Note: when converting the exception, if we have the message to match what the > older client expects, it can do re-authentication automatically, but we lost > the original message that server has thrown. (Need to consult the PM on what > kind of behavior they want). -- This message was sent by Atlassian Jira (v8.3.4#803005)
