[jira] [Assigned] (GEODE-10230) Support for PDX Update and Delete Endpoints in Management REST API

[Juan Ramos (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Juan Ramos reassigned GEODE-10230:
--

Assignee: Juan Ramos

> Support for PDX Update and Delete Endpoints in Management REST API
> --
>
> Key: GEODE-10230
> URL: https://issues.apache.org/jira/browse/GEODE-10230
> Project: Geode
>  Issue Type: Bug
>  Components: management, rest (admin)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: needsTriage
>
> Support for PDX Update and Delete Endpoints in Management REST API
> The cluster management REST API only exports CREATE and DELETE operations for 
> all currently supported configuration elements (region, gateway, pdx, etc.). 
> Even though several of the {{ConfigurationRealizer}}, 
> {{ConfigurationManager}} and {{ConfigurationValidator}} are already 
> implemented, the {{LocatorClusterManagementService}} always throws an 
> exception for UPDATE operations and the actual endpoints don't even exist on 
> the respective controllers.
> The above greatly limits the ability of consumers to use the management REST 
> API endpoints as the configurations can't be changed after creation time, 
> making some of them useless. As an example, a user probably doesn't know 
> before hand the full list of domain classes that need to be serialized using 
> the PDX auto-serializer. When using only the management REST API endpoints to 
> manage a cluster, this implies that the PDX cluster configuration becomes 
> useless as soon as an extra pattern needs to be added, forcing the user to 
> entirely re-create and re-populate the cluster from scratch.
> This ticket only aims to support delete and update operations for the PDX 
> configuration using the management REST API, the rest of the configuration 
> elements will remain forbidden (old behaviour will be kept by leveraging the 
> respective {{ConfigurationValidator}}) and must be incrementally added in the 
> future if needed.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-10230) Support for PDX Update and Delete Endpoints in Management REST API

[Juan Ramos (Jira)]

Juan Ramos created GEODE-10230:
--

 Summary: Support for PDX Update and Delete Endpoints in Management 
REST API
 Key: GEODE-10230
 URL: https://issues.apache.org/jira/browse/GEODE-10230
 Project: Geode
  Issue Type: Bug
  Components: management, rest (admin)
Affects Versions: 1.15.0
Reporter: Juan Ramos


Support for PDX Update and Delete Endpoints in Management REST API

The cluster management REST API only exports CREATE and DELETE operations for 
all currently supported configuration elements (region, gateway, pdx, etc.). 
Even though several of the {{ConfigurationRealizer}}, {{ConfigurationManager}} 
and {{ConfigurationValidator}} are already implemented, the 
{{LocatorClusterManagementService}} always throws an exception for UPDATE 
operations and the actual endpoints don't even exist on the respective 
controllers.
The above greatly limits the ability of consumers to use the management REST 
API endpoints as the configurations can't be changed after creation time, 
making some of them useless. As an example, a user probably doesn't know before 
hand the full list of domain classes that need to be serialized using the PDX 
auto-serializer. When using only the management REST API endpoints to manage a 
cluster, this implies that the PDX cluster configuration becomes useless as 
soon as an extra pattern needs to be added, forcing the user to entirely 
re-create and re-populate the cluster from scratch.

This ticket only aims to support delete and update operations for the PDX 
configuration using the management REST API, the rest of the configuration 
elements will remain forbidden (old behaviour will be kept by leveraging the 
respective {{ConfigurationValidator}}) and must be incrementally added in the 
future if needed.




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10230) Support for PDX Update and Delete Endpoints in Management REST API

[Alexander Murmann (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Murmann updated GEODE-10230:
--
Labels: needsTriage  (was: )

> Support for PDX Update and Delete Endpoints in Management REST API
> --
>
> Key: GEODE-10230
> URL: https://issues.apache.org/jira/browse/GEODE-10230
> Project: Geode
>  Issue Type: Bug
>  Components: management, rest (admin)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Priority: Major
>  Labels: needsTriage
>
> Support for PDX Update and Delete Endpoints in Management REST API
> The cluster management REST API only exports CREATE and DELETE operations for 
> all currently supported configuration elements (region, gateway, pdx, etc.). 
> Even though several of the {{ConfigurationRealizer}}, 
> {{ConfigurationManager}} and {{ConfigurationValidator}} are already 
> implemented, the {{LocatorClusterManagementService}} always throws an 
> exception for UPDATE operations and the actual endpoints don't even exist on 
> the respective controllers.
> The above greatly limits the ability of consumers to use the management REST 
> API endpoints as the configurations can't be changed after creation time, 
> making some of them useless. As an example, a user probably doesn't know 
> before hand the full list of domain classes that need to be serialized using 
> the PDX auto-serializer. When using only the management REST API endpoints to 
> manage a cluster, this implies that the PDX cluster configuration becomes 
> useless as soon as an extra pattern needs to be added, forcing the user to 
> entirely re-create and re-populate the cluster from scratch.
> This ticket only aims to support delete and update operations for the PDX 
> configuration using the management REST API, the rest of the configuration 
> elements will remain forbidden (old behaviour will be kept by leveraging the 
> respective {{ConfigurationValidator}}) and must be incrementally added in the 
> future if needed.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10230) Support for PDX Update and Delete Endpoints in Management REST API

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-10230:
---
Labels: needsTriage pull-request-available  (was: needsTriage)

> Support for PDX Update and Delete Endpoints in Management REST API
> --
>
> Key: GEODE-10230
> URL: https://issues.apache.org/jira/browse/GEODE-10230
> Project: Geode
>  Issue Type: Bug
>  Components: management, rest (admin)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: needsTriage, pull-request-available
>
> Support for PDX Update and Delete Endpoints in Management REST API
> The cluster management REST API only exports CREATE and DELETE operations for 
> all currently supported configuration elements (region, gateway, pdx, etc.). 
> Even though several of the {{ConfigurationRealizer}}, 
> {{ConfigurationManager}} and {{ConfigurationValidator}} are already 
> implemented, the {{LocatorClusterManagementService}} always throws an 
> exception for UPDATE operations and the actual endpoints don't even exist on 
> the respective controllers.
> The above greatly limits the ability of consumers to use the management REST 
> API endpoints as the configurations can't be changed after creation time, 
> making some of them useless. As an example, a user probably doesn't know 
> before hand the full list of domain classes that need to be serialized using 
> the PDX auto-serializer. When using only the management REST API endpoints to 
> manage a cluster, this implies that the PDX cluster configuration becomes 
> useless as soon as an extra pattern needs to be added, forcing the user to 
> entirely re-create and re-populate the cluster from scratch.
> This ticket only aims to support delete and update operations for the PDX 
> configuration using the management REST API, the rest of the configuration 
> elements will remain forbidden (old behaviour will be kept by leveraging the 
> respective {{ConfigurationValidator}}) and must be incrementally added in the 
> future if needed.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10161) Clean up synchronization in RedisList

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-10161:
---
Labels: pull-request-available  (was: )

> Clean up synchronization in RedisList
> -
>
> Key: GEODE-10161
> URL: https://issues.apache.org/jira/browse/GEODE-10161
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
>
> Prior to adding versioning, we needed {{synchronized}} on various helper 
> methods that modified the internal list data structure. This was in order to 
> ensure exclusive access in the event of a {{toData()}} call (during 
> GII/bucket movement). {{toData()}} is also synchronized. However, now that 
> we're synchronizing within more of the 'top-level' methods in RedisList, 
> (because we're also changing the {{version}} value), I think that we should 
> be able to remove all of the {{synchronized}} modifiers on the smaller helper 
> methods.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-10231) Add configuration for suppressing FunctionException logging

[Oleksii Sitnianskyi (Jira)]

Oleksii Sitnianskyi created GEODE-10231:
---

 Summary: Add configuration for suppressing FunctionException 
logging
 Key: GEODE-10231
 URL: https://issues.apache.org/jira/browse/GEODE-10231
 Project: Geode
  Issue Type: Improvement
  Components: client/server, functions
Reporter: Oleksii Sitnianskyi


According to Apache Geode function implementation, the following is stated in 
[1]:

"To propagate an error condition or exception back to the caller of the
function, throw a FunctionException from the execute method. Geode transmits the
exception back to the caller as if it had been thrown on the calling side. See
the Java API documentation for
FunctionException
for more information."

And as per [2]:
"if a GemFire client executes a Function on a server, and the function's execute
method throws a FunctionException, the server logs the exception as a warning,
and transmits it back to the calling client, which throws it"

So, for every FunctionException thrown by a user Server Function, the server
logs the exception with the corresponding stack trace.

This could imply, depending on the logic implemented in the user Server
Function, that the log of the server is packed with these messages (which
probably are not providing extra useful information given that the exception
will reach the client), and making it difficult to analyze the logs to find
other relevant events.

Given that Apache Geode recommends the use of FunctionException as the means to
propagate an error condition or exception back to the caller, we could argue if
a FunctionException thrown by a user Function should have any reflection, at
all, in the server logs. Besides, as said before, depending on the amount of the
exceptions generated, this can complicate the analysis of log files, require
much more space for logs storage and have a negative impact in performance.

The improvement for server side logging is adding system property configuration 
for surprising FunctionException logging.
Property example: 

{code}
gemfire.logging.suppressFunctionExceptionLogging=true

{code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-10231) Add configuration for suppressing FunctionException logging

[Oleksii Sitnianskyi (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleksii Sitnianskyi reassigned GEODE-10231:
---

Assignee: Oleksii Sitnianskyi

> Add configuration for suppressing FunctionException logging
> ---
>
> Key: GEODE-10231
> URL: https://issues.apache.org/jira/browse/GEODE-10231
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, functions
>Reporter: Oleksii Sitnianskyi
>Assignee: Oleksii Sitnianskyi
>Priority: Major
>
> According to Apache Geode function implementation, the following is stated in 
> [1]:
> "To propagate an error condition or exception back to the caller of the
> function, throw a FunctionException from the execute method. Geode transmits 
> the
> exception back to the caller as if it had been thrown on the calling side. See
> the Java API documentation for
> FunctionException
> for more information."
> And as per [2]:
> "if a GemFire client executes a Function on a server, and the function's 
> execute
> method throws a FunctionException, the server logs the exception as a warning,
> and transmits it back to the calling client, which throws it"
> So, for every FunctionException thrown by a user Server Function, the server
> logs the exception with the corresponding stack trace.
> This could imply, depending on the logic implemented in the user Server
> Function, that the log of the server is packed with these messages (which
> probably are not providing extra useful information given that the exception
> will reach the client), and making it difficult to analyze the logs to find
> other relevant events.
> Given that Apache Geode recommends the use of FunctionException as the means 
> to
> propagate an error condition or exception back to the caller, we could argue 
> if
> a FunctionException thrown by a user Function should have any reflection, at
> all, in the server logs. Besides, as said before, depending on the amount of 
> the
> exceptions generated, this can complicate the analysis of log files, require
> much more space for logs storage and have a negative impact in performance.
> The improvement for server side logging is adding system property 
> configuration for surprising FunctionException logging.
> Property example: 
> {code}
> gemfire.logging.suppressFunctionExceptionLogging=true
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10231) Add configuration for suppressing FunctionException logging

[Oleksii Sitnianskyi (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleksii Sitnianskyi updated GEODE-10231:

Priority: Minor  (was: Major)

> Add configuration for suppressing FunctionException logging
> ---
>
> Key: GEODE-10231
> URL: https://issues.apache.org/jira/browse/GEODE-10231
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, functions
>Reporter: Oleksii Sitnianskyi
>Assignee: Oleksii Sitnianskyi
>Priority: Minor
>
> According to Apache Geode function implementation, the following is stated in 
> [1]:
> "To propagate an error condition or exception back to the caller of the
> function, throw a FunctionException from the execute method. Geode transmits 
> the
> exception back to the caller as if it had been thrown on the calling side. See
> the Java API documentation for
> FunctionException
> for more information."
> And as per [2]:
> "if a GemFire client executes a Function on a server, and the function's 
> execute
> method throws a FunctionException, the server logs the exception as a warning,
> and transmits it back to the calling client, which throws it"
> So, for every FunctionException thrown by a user Server Function, the server
> logs the exception with the corresponding stack trace.
> This could imply, depending on the logic implemented in the user Server
> Function, that the log of the server is packed with these messages (which
> probably are not providing extra useful information given that the exception
> will reach the client), and making it difficult to analyze the logs to find
> other relevant events.
> Given that Apache Geode recommends the use of FunctionException as the means 
> to
> propagate an error condition or exception back to the caller, we could argue 
> if
> a FunctionException thrown by a user Function should have any reflection, at
> all, in the server logs. Besides, as said before, depending on the amount of 
> the
> exceptions generated, this can complicate the analysis of log files, require
> much more space for logs storage and have a negative impact in performance.
> The improvement for server side logging is adding system property 
> configuration for surprising FunctionException logging.
> Property example: 
> {code}
> gemfire.logging.suppressFunctionExceptionLogging=true
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10231) Add configuration for suppressing FunctionException logging

[Oleksii Sitnianskyi (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleksii Sitnianskyi updated GEODE-10231:

Priority: Major  (was: Minor)

> Add configuration for suppressing FunctionException logging
> ---
>
> Key: GEODE-10231
> URL: https://issues.apache.org/jira/browse/GEODE-10231
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, functions
>Reporter: Oleksii Sitnianskyi
>Assignee: Oleksii Sitnianskyi
>Priority: Major
>
> According to Apache Geode function implementation, the following is stated in 
> [1]:
> "To propagate an error condition or exception back to the caller of the
> function, throw a FunctionException from the execute method. Geode transmits 
> the
> exception back to the caller as if it had been thrown on the calling side. See
> the Java API documentation for
> FunctionException
> for more information."
> And as per [2]:
> "if a GemFire client executes a Function on a server, and the function's 
> execute
> method throws a FunctionException, the server logs the exception as a warning,
> and transmits it back to the calling client, which throws it"
> So, for every FunctionException thrown by a user Server Function, the server
> logs the exception with the corresponding stack trace.
> This could imply, depending on the logic implemented in the user Server
> Function, that the log of the server is packed with these messages (which
> probably are not providing extra useful information given that the exception
> will reach the client), and making it difficult to analyze the logs to find
> other relevant events.
> Given that Apache Geode recommends the use of FunctionException as the means 
> to
> propagate an error condition or exception back to the caller, we could argue 
> if
> a FunctionException thrown by a user Function should have any reflection, at
> all, in the server logs. Besides, as said before, depending on the amount of 
> the
> exceptions generated, this can complicate the analysis of log files, require
> much more space for logs storage and have a negative impact in performance.
> The improvement for server side logging is adding system property 
> configuration for surprising FunctionException logging.
> Property example: 
> {code}
> gemfire.logging.suppressFunctionExceptionLogging=true
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520656#comment-17520656
 ] 

ASF subversion and git services commented on GEODE-10097:
-

Commit 4fbc35c29ef131f8d8f1f82391d224f3c2bbc346 in geode's branch 
refs/heads/develop from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4fbc35c29e ]

GEODE-10097: Avoid Thread.sleep for re-auth in MessageDispatcher (#7556)



> Do not use Thread.sleep in MessageDispatcher for re-authentication feature
> --
>
> Key: GEODE-10097
> URL: https://issues.apache.org/jira/browse/GEODE-10097
> Project: Geode
>  Issue Type: Improvement
>  Components: client queues, client/server
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> MessageDispatcher uses Thread.sleep and wakes up intervals to recheck 
> authorization to see if new subject has re-logged in or not, if not, it will 
> call "authorize" again and again till timeout. Suggest using "wait/notify" 
> mechanism to wait for the subject to be updated, this way we don't use 
> Thread.sleep and not place unnecessary calls to the security manager.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10209) [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520662#comment-17520662
 ] 

Geode Integration commented on GEODE-10209:
---

Seen in [distributed-test-openjdk11 
#281|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/281]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1088/test-results/distributedTest/1649471056/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1088/test-artifacts/1649471056/distributedtestfiles-openjdk11-1.15.0-build.1088.tgz].

> [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
> 
>
> Key: GEODE-10209
> URL: https://issues.apache.org/jira/browse/GEODE-10209
> Project: Geode
>  Issue Type: Bug
>  Components: ci
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
>
> This test class needs to be refactored to use AvailablePortHelper
> {code:java}
> InternalCacheForClientAccessDistributedTest > serverUsesFilteredCache FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple 
> Failures (2 failures)
>   org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$402/0x000100357c40.run
>  in VM 0 running on Host 
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal 
> with 4 VMs
>   org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$404/0x000100354840.run
>  in VM 1 running on Host 
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal 
> with 4 VMs
> at 
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at 
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at 
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at 
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at 
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at 
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at 
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at 
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at 
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at 
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at 
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at 
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at 
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
>   

[jira] [Commented] (GEODE-10209) [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520663#comment-17520663
 ] 

Geode Integration commented on GEODE-10209:
---

Seen in [distributed-test-openjdk8 
#1855|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1855]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649513773/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649513773/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
> 
>
> Key: GEODE-10209
> URL: https://issues.apache.org/jira/browse/GEODE-10209
> Project: Geode
>  Issue Type: Bug
>  Components: ci
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
>
> This test class needs to be refactored to use AvailablePortHelper
> {code:java}
> InternalCacheForClientAccessDistributedTest > serverUsesFilteredCache FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple 
> Failures (2 failures)
>   org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$402/0x000100357c40.run
>  in VM 0 running on Host 
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal 
> with 4 VMs
>   org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$404/0x000100354840.run
>  in VM 1 running on Host 
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal 
> with 4 VMs
> at 
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at 
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at 
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at 
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at 
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at 
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at 
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at 
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at 
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at 
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at 
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at 
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at 
> org.junit.platform.launcher.core.DefaultLauncher.execute(Default

[jira] [Commented] (GEODE-10209) [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520665#comment-17520665
 ] 

Geode Integration commented on GEODE-10209:
---

Seen in [distributed-test-openjdk8 
#1817|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1817]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649478622/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649478622/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
> 
>
> Key: GEODE-10209
> URL: https://issues.apache.org/jira/browse/GEODE-10209
> Project: Geode
>  Issue Type: Bug
>  Components: ci
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
>
> This test class needs to be refactored to use AvailablePortHelper
> {code:java}
> InternalCacheForClientAccessDistributedTest > serverUsesFilteredCache FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple 
> Failures (2 failures)
>   org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$402/0x000100357c40.run
>  in VM 0 running on Host 
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal 
> with 4 VMs
>   org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$404/0x000100354840.run
>  in VM 1 running on Host 
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal 
> with 4 VMs
> at 
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at 
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at 
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at 
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at 
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at 
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at 
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at 
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at 
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at 
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at 
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at 
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at 
> org.junit.platform.launcher.core.DefaultLauncher.execute(Default

[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520668#comment-17520668
 ] 

Geode Integration commented on GEODE-7710:
--

Seen in [distributed-test-openjdk8 
#1891|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1891]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649546869/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649546869/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest 
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
>  Labels: GeodeOperationAPI, flaky, pull-request-available
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> This test fails due to GEODE-7739. Enter new failures against that ticket.
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of 
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>  
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520669#comment-17520669
 ] 

Geode Integration commented on GEODE-7710:
--

Seen in [distributed-test-openjdk8 
#1888|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1888]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649540141/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649540141/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest 
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
>  Labels: GeodeOperationAPI, flaky, pull-request-available
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> This test fails due to GEODE-7739. Enter new failures against that ticket.
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of 
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>  
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520671#comment-17520671
 ] 

Geode Integration commented on GEODE-7739:
--

Seen in [distributed-test-openjdk8 
#1885|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1885]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649537999/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649537999/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> JMX managers may fail to federate mbeans for other members
> --
>
> Key: GEODE-7739
> URL: https://issues.apache.org/jira/browse/GEODE-7739
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JMX Manager may fail to federate one or more MXBeans for other members 
> because of a race condition during startup. When ManagementCacheListener is 
> first constructed, it is in a state that will ignore all callbacks because 
> the field readyForEvents is false.
> 
> Debugging with JMXMBeanReconnectDUnitTest revealed this bug.
> The test starts two locators with jmx manager configured and started. 
> Locator1 always has all of locator2's mbeans, but locator2 is intermittently 
> missing the personal mbeans of locator1. 
> I think this is caused by some sort of race condition in the code that 
> creates the monitoring regions for other members in locator2.
> It's possible that the jmx manager that hits this bug might fail to have 
> mbeans for servers as well as other locators but I haven't seen a test case 
> for this scenario.
> The exposure of this bug means that a user running more than one locator 
> might have a locator that is missing one or more mbeans for the cluster.
> 
> Studying the JMX code also reveals the existence of *GEODE-8012*.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520670#comment-17520670
 ] 

Geode Integration commented on GEODE-7739:
--

Seen in [distributed-test-openjdk8 
#1880|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1880]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649532184/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649532184/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> JMX managers may fail to federate mbeans for other members
> --
>
> Key: GEODE-7739
> URL: https://issues.apache.org/jira/browse/GEODE-7739
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JMX Manager may fail to federate one or more MXBeans for other members 
> because of a race condition during startup. When ManagementCacheListener is 
> first constructed, it is in a state that will ignore all callbacks because 
> the field readyForEvents is false.
> 
> Debugging with JMXMBeanReconnectDUnitTest revealed this bug.
> The test starts two locators with jmx manager configured and started. 
> Locator1 always has all of locator2's mbeans, but locator2 is intermittently 
> missing the personal mbeans of locator1. 
> I think this is caused by some sort of race condition in the code that 
> creates the monitoring regions for other members in locator2.
> It's possible that the jmx manager that hits this bug might fail to have 
> mbeans for servers as well as other locators but I haven't seen a test case 
> for this scenario.
> The exposure of this bug means that a user running more than one locator 
> might have a locator that is missing one or more mbeans for the cluster.
> 
> Studying the JMX code also reveals the existence of *GEODE-8012*.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520672#comment-17520672
 ] 

Geode Integration commented on GEODE-7739:
--

Seen in [distributed-test-openjdk8 
#1824|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1824]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649487130/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649487130/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> JMX managers may fail to federate mbeans for other members
> --
>
> Key: GEODE-7739
> URL: https://issues.apache.org/jira/browse/GEODE-7739
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JMX Manager may fail to federate one or more MXBeans for other members 
> because of a race condition during startup. When ManagementCacheListener is 
> first constructed, it is in a state that will ignore all callbacks because 
> the field readyForEvents is false.
> 
> Debugging with JMXMBeanReconnectDUnitTest revealed this bug.
> The test starts two locators with jmx manager configured and started. 
> Locator1 always has all of locator2's mbeans, but locator2 is intermittently 
> missing the personal mbeans of locator1. 
> I think this is caused by some sort of race condition in the code that 
> creates the monitoring regions for other members in locator2.
> It's possible that the jmx manager that hits this bug might fail to have 
> mbeans for servers as well as other locators but I haven't seen a test case 
> for this scenario.
> The exposure of this bug means that a user running more than one locator 
> might have a locator that is missing one or more mbeans for the cluster.
> 
> Studying the JMX code also reveals the existence of *GEODE-8012*.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520674#comment-17520674
 ] 

Geode Integration commented on GEODE-6222:
--

Seen in [distributed-test-openjdk8 
#1898|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1898]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649548889/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649548889/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: GemFireDeadlockDetectorDUnitTest
> 
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
>  Issue Type: Bug
>  Components: distributed lock service
>Affects Versions: 1.9.0, 1.14.0, 1.15.0
>Reporter: Ken Howe
>Priority: Major
>  Labels: flaky
>
> Flaky test failure in 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
>  > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520675#comment-17520675
 ] 

Geode Integration commented on GEODE-6222:
--

Seen in [distributed-test-openjdk8 
#1894|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1894]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649547670/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649547670/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: GemFireDeadlockDetectorDUnitTest
> 
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
>  Issue Type: Bug
>  Components: distributed lock service
>Affects Versions: 1.9.0, 1.14.0, 1.15.0
>Reporter: Ken Howe
>Priority: Major
>  Labels: flaky
>
> Flaky test failure in 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
>  > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520676#comment-17520676
 ] 

Geode Integration commented on GEODE-6222:
--

Seen in [distributed-test-openjdk8 
#1820|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1820]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649480575/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649480575/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: GemFireDeadlockDetectorDUnitTest
> 
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
>  Issue Type: Bug
>  Components: distributed lock service
>Affects Versions: 1.9.0, 1.14.0, 1.15.0
>Reporter: Ken Howe
>Priority: Major
>  Labels: flaky
>
> Flaky test failure in 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
>  > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520684#comment-17520684
 ] 

Geode Integration commented on GEODE-10228:
---

Seen in [distributed-test-openjdk8 
#1837|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1837]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649497875/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649497875/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await 
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do 
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running 
> on Host 
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase 
> expected: null
>  but was: "0"="0" within 5 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError: 
> expected: null
>  but was: "0"="0"
> at 
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520683#comment-17520683
 ] 

Geode Integration commented on GEODE-10228:
---

Seen in [distributed-test-openjdk8 
#1847|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1847]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649505340/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649505340/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await 
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do 
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running 
> on Host 
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase 
> expected: null
>  but was: "0"="0" within 5 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError: 
> expected: null
>  but was: "0"="0"
> at 
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520682#comment-17520682
 ] 

Geode Integration commented on GEODE-10228:
---

Seen in [distributed-test-openjdk8 
#1852|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1852]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649512890/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649512890/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await 
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do 
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running 
> on Host 
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase 
> expected: null
>  but was: "0"="0" within 5 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError: 
> expected: null
>  but was: "0"="0"
> at 
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520686#comment-17520686
 ] 

Geode Integration commented on GEODE-10228:
---

Seen in [distributed-test-openjdk8 
#1829|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1829]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649488285/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649488285/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await 
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do 
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running 
> on Host 
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase 
> expected: null
>  but was: "0"="0" within 5 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError: 
> expected: null
>  but was: "0"="0"
> at 
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520689#comment-17520689
 ] 

Geode Integration commented on GEODE-10228:
---

Seen in [distributed-test-openjdk8 
#1808|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1808]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649470744/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649470744/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await 
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do 
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running 
> on Host 
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase 
> expected: null
>  but was: "0"="0" within 5 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError: 
> expected: null
>  but was: "0"="0"
> at 
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520687#comment-17520687
 ] 

Geode Integration commented on GEODE-10228:
---

Seen in [distributed-test-openjdk8 
#1818|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1818]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649479757/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649479757/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await 
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do 
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running 
> on Host 
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase 
> expected: null
>  but was: "0"="0" within 5 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError: 
> expected: null
>  but was: "0"="0"
> at 
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520688#comment-17520688
 ] 

Geode Integration commented on GEODE-10228:
---

Seen in [distributed-test-openjdk8 
#1887|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1887]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649539902/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649539902/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await 
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do 
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running 
> on Host 
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase 
> expected: null
>  but was: "0"="0" within 5 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError: 
> expected: null
>  but was: "0"="0"
> at 
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520692#comment-17520692
 ] 

Geode Integration commented on GEODE-10228:
---

Seen in [distributed-test-openjdk8 
#1801|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1801]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649471092/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649471092/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await 
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do 
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running 
> on Host 
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase 
> expected: null
>  but was: "0"="0" within 5 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError: 
> expected: null
>  but was: "0"="0"
> at 
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10186) CI failure: RedundancyLevelPart1DUnitTest > testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU times out waiting for getClientProxies() to return more than 0 objec

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520696#comment-17520696
 ] 

Geode Integration commented on GEODE-10186:
---

Seen in [distributed-test-openjdk8 
#1814|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1814]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649478614/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649478614/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> CI failure: RedundancyLevelPart1DUnitTest > 
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU times out waiting for 
> getClientProxies() to return more than 0 objects
> -
>
> Key: GEODE-10186
> URL: https://issues.apache.org/jira/browse/GEODE-10186
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14277358]
>  
> {noformat}
> > Task :geode-core:distributedTest
> RedundancyLevelPart1DUnitTest > 
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest$$Lambda$543/510122765.run
>  in VM 2 running on Host 
> heavy-lifter-f58561da-caf9-5bc0-a7fa-f938c3fd1e51.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at 
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU(RedundancyLevelPart1DUnitTest.java:284)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest 
> that uses org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier 
> Expecting actual:
>   0
> to be greater than:
>   0
>  within 5 minutes.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at 
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.verifyInterestRegistration(RedundancyLevelPart1DUnitTest.java:505)
> Caused by:
> java.lang.AssertionError: 
> Expecting actual:
>   0
> to be greater than:
>   0
> at 
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.lambda$verifyInterestRegistration$19(RedundancyLevelPart1DUnitTest.java:506)
> 8352 tests completed, 1 failed, 414 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1033/test-results/distributedTest/1648331031/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1033/test-artifacts/1648331031/distributedtestfiles-openjdk8-1.15.0-build.1033.tgz
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-7988) AutoConnectionSourceDUnitTest. testClientDynamicallyDropsStoppedLocator is failing in mass test run

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520697#comment-17520697
 ] 

Geode Integration commented on GEODE-7988:
--

Seen in [distributed-test-openjdk8 
#1825|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1825]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-results/distributedTest/1649488661/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1088/test-artifacts/1649488661/distributedtestfiles-openjdk8-1.15.0-build.1088.tgz].

> AutoConnectionSourceDUnitTest. testClientDynamicallyDropsStoppedLocator is 
> failing in mass test run
> ---
>
> Key: GEODE-7988
> URL: https://issues.apache.org/jira/browse/GEODE-7988
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.13.0
>Reporter: Mark Hanson
>Priority: Major
>  Labels: flaky
>
> {noformat}
> testClientDynamicallyDropsStoppedLocator
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1993
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1940
>  {noformat}
>  
> This is also reproducible using dunitrunner.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GEODE-9704) When durable clients recovers, it sends "ready for event" signal before register for interest, this might cause problem for caching_proxy regions

[Mark Hanson (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Hanson resolved GEODE-9704.

Fix Version/s: 1.15.0
   Resolution: Fixed

> When durable clients recovers, it sends "ready for event" signal before 
> register for interest, this might cause problem for caching_proxy regions
> -
>
> Key: GEODE-9704
> URL: https://issues.apache.org/jira/browse/GEODE-9704
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.15.0
>Reporter: Jinmei Liao
>Assignee: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI, blocks-1.15.1, pull-request-available
> Fix For: 1.15.0
>
>
> This is the old Geode behavior, but may or may not be the correct behavior.
> When durable clients recovers, there is a queueTimer thread that runs 
> `QueueManagerImp.recoverPrimary` method,  it 
>  * makes new connection to server
>  - sends readyForEvents (which will cause the server to start sending the 
> queued events)
>  - recovers interest
>   - clears the region of keys of interest
>   - re-registers interest
> It sends readyForEvents before it clears region of keys of interest, if 
> server sends some events of those keys in between, it will clear them, thus 
> it seems to the user that the client region doesn't have those keys. 
>  
> Run geode-core distributedTest 
> AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(),
>  change the InterestResultPolicy to NONE, you would see the test would fail 
> occasionally, Adding sleep code in QueueManagerImp.recoverPrimary between 
> `createNewPrimary` and `recoverInterest` would make the test fail more 
> consistently.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10193) QueryPdxDataDUnitTest accesses Unsafe field that does not exist on JDK 17

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-10193:
---
Labels: Java17 pull-request-available  (was: Java17)

> QueryPdxDataDUnitTest accesses Unsafe field that does not exist on JDK 17
> -
>
> Key: GEODE-10193
> URL: https://issues.apache.org/jira/browse/GEODE-10193
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
>  Labels: Java17, pull-request-available
>
> The {{QueryPdxDataDUnitTest}} class setup method uses the 
> {{net.openhft.compiler}} library's {{CachedCompiler}} to dynamically build 
> several java classes in child VMs. The {{CacheCompiler}} class's static 
> initializer attempts to access the {{override}} field of the system's 
> {{Unsafe}} instance. On JDK 17, the attempt throws 
> {{{}NoSuchFieldException{}}}.
> Stack trace:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.management.QueryPdxDataDUnitTest$$Lambda$489/0x0008010cd4b8.run
>  in VM 3 running on Host 
> heavy-lifter-03dd4ef3-5b5a-50e9-a355-9c3a43ac89c7.c.apachegeode-ci.internal 
> with 4 VMs
>   at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
>   at 
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
>   at 
> org.apache.geode.management.QueryPdxDataDUnitTest.beforeClass(QueryPdxDataDUnitTest.java:81)
>   at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:568)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>   at 
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
>   at 
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
>   at 
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
>   at 
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
>   at 
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
>   at 
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
>   at 
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
>   at 
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
>   at 
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
>   at 
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
>   at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> jdk.internal.

[jira] [Closed] (GEODE-10219) CI Failure: geode-assembly:acceptanceTest failing for support/1.12 and support/1.13

[Kirk Lund (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund closed GEODE-10219.
-

> CI Failure: geode-assembly:acceptanceTest failing for support/1.12 and 
> support/1.13
> ---
>
> Key: GEODE-10219
> URL: https://issues.apache.org/jira/browse/GEODE-10219
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.12.10, 1.13.9
>Reporter: Joris Melchior
>Assignee: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.12.10, 1.13.9
>
>
> Repeated failure of `acceptance-test-openjdk11` with tests being unable to 
> properly shut down members as part of the tests.
> See 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/acceptance-test-openjdk11/builds/51]
> See 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/acceptance-test-openjdk11/builds/42]
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GEODE-10219) CI Failure: geode-assembly:acceptanceTest failing for support/1.12 and support/1.13

[Kirk Lund (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund resolved GEODE-10219.
---
Fix Version/s: 1.12.10
   1.13.9
   Resolution: Fixed

Fixed by reverting serialization filter backports.

> CI Failure: geode-assembly:acceptanceTest failing for support/1.12 and 
> support/1.13
> ---
>
> Key: GEODE-10219
> URL: https://issues.apache.org/jira/browse/GEODE-10219
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.12.10, 1.13.9
>Reporter: Joris Melchior
>Assignee: Kirk Lund
>Priority: Major
>  Labels: needsTriage
> Fix For: 1.12.10, 1.13.9
>
>
> Repeated failure of `acceptance-test-openjdk11` with tests being unable to 
> properly shut down members as part of the tests.
> See 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/acceptance-test-openjdk11/builds/51]
> See 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/acceptance-test-openjdk11/builds/42]
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-10232) User Guide - reformat list for more reliable rendering

[Dave Barnes (Jira)]

Dave Barnes created GEODE-10232:
---

 Summary: User Guide - reformat list for more reliable rendering
 Key: GEODE-10232
 URL: https://issues.apache.org/jira/browse/GEODE-10232
 Project: Geode
  Issue Type: Improvement
  Components: docs
Affects Versions: 1.14.4
Reporter: Dave Barnes


The How Function Execution Works page contains a bullet list with bold elements 
and en-dashes (apparently entered via keyboard shortcuts) that are not always 
interpreted in the same way by different Markdown interpreters.
https://geode.apache.org/docs/guide/114/developing/function_exec/how_function_execution_works.html

Simplify the layout for more reliable output across various flavors of Markdown.
Suggested modification: Replace each en-dash with a colon+space combination.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-10232) User Guide - reformat list for more reliable rendering

[Dave Barnes (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Barnes reassigned GEODE-10232:
---

Assignee: Dave Barnes

> User Guide - reformat list for more reliable rendering
> --
>
> Key: GEODE-10232
> URL: https://issues.apache.org/jira/browse/GEODE-10232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Affects Versions: 1.14.4
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
>
> The How Function Execution Works page contains a bullet list with bold 
> elements and en-dashes (apparently entered via keyboard shortcuts) that are 
> not always interpreted in the same way by different Markdown interpreters.
> https://geode.apache.org/docs/guide/114/developing/function_exec/how_function_execution_works.html
> Simplify the layout for more reliable output across various flavors of 
> Markdown.
> Suggested modification: Replace each en-dash with a colon+space combination.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10232) User Guide - reformat list for more reliable rendering

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-10232:
---
Labels: pull-request-available  (was: )

> User Guide - reformat list for more reliable rendering
> --
>
> Key: GEODE-10232
> URL: https://issues.apache.org/jira/browse/GEODE-10232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Affects Versions: 1.14.4
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
>  Labels: pull-request-available
>
> The How Function Execution Works page contains a bullet list with bold 
> elements and en-dashes (apparently entered via keyboard shortcuts) that are 
> not always interpreted in the same way by different Markdown interpreters.
> https://geode.apache.org/docs/guide/114/developing/function_exec/how_function_execution_works.html
> Simplify the layout for more reliable output across various flavors of 
> Markdown.
> Suggested modification: Replace each en-dash with a colon+space combination.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10225) Make gfsh start commands compatible with JDK 17

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520752#comment-17520752
 ] 

ASF subversion and git services commented on GEODE-10225:
-

Commit 16020446dfa81e91bc9263391a84563fc1d3a9f0 in geode's branch 
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=16020446df ]

GEODE-10225: Gfsh start commands add exports on JDK 11+ (#7572)

PROBLEM

When run on JDK 17, numerous acceptance tests fail because a launched
locator or server requires access to the following packages:
- java.base/sun.nio.ch
- java.management/com.sun.jmx.remote.security

SOLUTION

- Add a `MemberJvmOptions` class that reports the JDK-dependent options
  required to launch a locator or server on the current process's JDK.
- Change `StartLocatorCommand` and `StartServerCommand` to add those
  options to the command line when launching locators and servers.

FUTURE

Future PRs will likely put these opens/exports in an argument file, then
configure these commands to use the argument file. We are deferring that
until we identify additional needs for the argument file, so we can
choose an appropriate location for the argument file.

Co-authored-by: Dale Emery 
Co-authored-by: Kirk Lund 

Co-authored-by: Kirk Lund 

> Make gfsh start commands compatible with JDK 17
> ---
>
> Key: GEODE-10225
> URL: https://issues.apache.org/jira/browse/GEODE-10225
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: Java17, pull-request-available
>
> When run on JDK 17, numerous acceptance tests fail because a launched locator 
> or server requires access to the following packages:
>  - java.base/sun.nio.ch
>  - java.management/com.sun.jmx.remote.security
> When starting locators and servers, gfsh's {{StartLocatorCommand}} and 
> {{StartServerCommand}} should export these packages to all unnamed modules.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GEODE-10225) Make gfsh start commands compatible with JDK 17

[Dale Emery (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale Emery resolved GEODE-10225.

Fix Version/s: 1.15.0
   Resolution: Fixed

> Make gfsh start commands compatible with JDK 17
> ---
>
> Key: GEODE-10225
> URL: https://issues.apache.org/jira/browse/GEODE-10225
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> When run on JDK 17, numerous acceptance tests fail because a launched locator 
> or server requires access to the following packages:
>  - java.base/sun.nio.ch
>  - java.management/com.sun.jmx.remote.security
> When starting locators and servers, gfsh's {{StartLocatorCommand}} and 
> {{StartServerCommand}} should export these packages to all unnamed modules.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-10193) QueryPdxDataDUnitTest accesses Unsafe field that does not exist on JDK 17

[Dale Emery (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale Emery reassigned GEODE-10193:
--

Assignee: Dale Emery

> QueryPdxDataDUnitTest accesses Unsafe field that does not exist on JDK 17
> -
>
> Key: GEODE-10193
> URL: https://issues.apache.org/jira/browse/GEODE-10193
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: Java17, pull-request-available
>
> The {{QueryPdxDataDUnitTest}} class setup method uses the 
> {{net.openhft.compiler}} library's {{CachedCompiler}} to dynamically build 
> several java classes in child VMs. The {{CacheCompiler}} class's static 
> initializer attempts to access the {{override}} field of the system's 
> {{Unsafe}} instance. On JDK 17, the attempt throws 
> {{{}NoSuchFieldException{}}}.
> Stack trace:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.management.QueryPdxDataDUnitTest$$Lambda$489/0x0008010cd4b8.run
>  in VM 3 running on Host 
> heavy-lifter-03dd4ef3-5b5a-50e9-a355-9c3a43ac89c7.c.apachegeode-ci.internal 
> with 4 VMs
>   at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
>   at 
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
>   at 
> org.apache.geode.management.QueryPdxDataDUnitTest.beforeClass(QueryPdxDataDUnitTest.java:81)
>   at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:568)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>   at 
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
>   at 
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
>   at 
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
>   at 
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
>   at 
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
>   at 
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
>   at 
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
>   at 
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
>   at 
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
>   at 
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
>   at 
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
>   at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> jdk.internal

[jira] [Created] (GEODE-10233) User guide: Improve format of cache elements and client-cache elements reference pages

[Dave Barnes (Jira)]

Dave Barnes created GEODE-10233:
---

 Summary: User guide: Improve format of cache elements and 
client-cache elements reference pages
 Key: GEODE-10233
 URL: https://issues.apache.org/jira/browse/GEODE-10233
 Project: Geode
  Issue Type: Improvement
  Components: docs
Affects Versions: 1.14.4
Reporter: Dave Barnes


The reference pages for cache.xml and client_cache.xml use 3-column tables to 
describe their respective elements.
* https://geode.apache.org/docs/guide/114/reference/topics/cache_xml.html
* https://geode.apache.org/docs/guide/114/reference/topics/client-cache.html

Problem: Almost all content is confined to Column 2. Columns 1 and 3 contain 
very little content. Column 2 even contains nested tables and sample code. This 
presentation is very hard to read, and very hard to search or browse.

For example, see the table in cache_xml.html describing 
 attributes.

Solution: Devise a better format that's easier to read and better adapted to 
searching and browsing. An outline structure with headings, subheadings, and 
paragraphs would be one suggestion.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10184) CI failure on windows: non-zero exit status on gfsh command in DeployWithLargeJarTest > deployLargeSetOfJars

[Patrick Johnsn (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-10184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520783#comment-17520783
 ] 

Patrick Johnsn commented on GEODE-10184:


The problem is caused by the way Windows handles concurrent file access. We 
check that the status file exists, and then if it does, try to read it. This 
will sometimes fail on Windows if the file is being accessed by another 
process. The solution is to check not only if the file exists, but also if it 
can be opened before trying to read from it. Once opened, it must remain open 
until we are done with it, to avoid a race condition where another process 
could get ahold of it between the check and the read.

> CI failure on windows: non-zero exit status on gfsh command in 
> DeployWithLargeJarTest > deployLargeSetOfJars
> 
>
> Key: GEODE-10184
> URL: https://issues.apache.org/jira/browse/GEODE-10184
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Patrick Johnsn
>Priority: Major
>  Labels: needsTriage
>
> Deploy large jar test fails due to non-zero exit status on gfsh command on 
> windows
>  
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291025]
>  
> {noformat}
> > Task :geode-assembly:acceptanceTest
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by 
> [e66e7d3e01750dd9: gfsh -e start locator --name=locator --max-heap=128m -e 
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1 
> -e deploy 
> --jars=C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-beanutils-1.9.4.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-codec-1.15.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-collections-3.2.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-digester-2.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-io-2.11.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-lang3-3.12.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-logging-1.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-modeler-2.0.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-validator-1.7.jar]]
>  
> expected: 0
>  but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at 
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> 176 tests completed, 1 failed, 18 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/acceptanceTest/1648482211/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648482211/windows-acceptancetestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10184) CI failure on windows: non-zero exit status on gfsh command in DeployWithLargeJarTest > deployLargeSetOfJars

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-10184:
---
Labels: needsTriage pull-request-available  (was: needsTriage)

> CI failure on windows: non-zero exit status on gfsh command in 
> DeployWithLargeJarTest > deployLargeSetOfJars
> 
>
> Key: GEODE-10184
> URL: https://issues.apache.org/jira/browse/GEODE-10184
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Patrick Johnsn
>Priority: Major
>  Labels: needsTriage, pull-request-available
>
> Deploy large jar test fails due to non-zero exit status on gfsh command on 
> windows
>  
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291025]
>  
> {noformat}
> > Task :geode-assembly:acceptanceTest
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by 
> [e66e7d3e01750dd9: gfsh -e start locator --name=locator --max-heap=128m -e 
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1 
> -e deploy 
> --jars=C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-beanutils-1.9.4.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-codec-1.15.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-collections-3.2.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-digester-2.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-io-2.11.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-lang3-3.12.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-logging-1.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-modeler-2.0.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-validator-1.7.jar]]
>  
> expected: 0
>  but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at 
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> 176 tests completed, 1 failed, 18 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/acceptanceTest/1648482211/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648482211/windows-acceptancetestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled

[Eric Shu (Jira)]

Eric Shu created GEODE-10234:


 Summary: No need to generate tailKey for transaction if there is 
no parallel wan enabled
 Key: GEODE-10234
 URL: https://issues.apache.org/jira/browse/GEODE-10234
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Eric Shu


There is no need to generate a tailKey, if there is no parallel wan enabled. 
However, currently every operation on a partitioned region would generate such 
key and will be ignored anyway.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled

[Eric Shu (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Shu updated GEODE-10234:
-
Affects Version/s: 1.12.0

> No need to generate tailKey for transaction if there is no parallel wan 
> enabled
> ---
>
> Key: GEODE-10234
> URL: https://issues.apache.org/jira/browse/GEODE-10234
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.12.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>
> There is no need to generate a tailKey, if there is no parallel wan enabled. 
> However, currently every operation on a partitioned region would generate 
> such key and will be ignored anyway.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled

[Alexander Murmann (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Murmann updated GEODE-10234:
--
Labels: needsTriage  (was: )

> No need to generate tailKey for transaction if there is no parallel wan 
> enabled
> ---
>
> Key: GEODE-10234
> URL: https://issues.apache.org/jira/browse/GEODE-10234
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Priority: Major
>  Labels: needsTriage
>
> There is no need to generate a tailKey, if there is no parallel wan enabled. 
> However, currently every operation on a partitioned region would generate 
> such key and will be ignored anyway.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled

[Eric Shu (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Shu updated GEODE-10234:
-
Labels:   (was: needsTriage)

> No need to generate tailKey for transaction if there is no parallel wan 
> enabled
> ---
>
> Key: GEODE-10234
> URL: https://issues.apache.org/jira/browse/GEODE-10234
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>
> There is no need to generate a tailKey, if there is no parallel wan enabled. 
> However, currently every operation on a partitioned region would generate 
> such key and will be ignored anyway.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled

[Eric Shu (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Shu reassigned GEODE-10234:


Assignee: Eric Shu

> No need to generate tailKey for transaction if there is no parallel wan 
> enabled
> ---
>
> Key: GEODE-10234
> URL: https://issues.apache.org/jira/browse/GEODE-10234
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: needsTriage
>
> There is no need to generate a tailKey, if there is no parallel wan enabled. 
> However, currently every operation on a partitioned region would generate 
> such key and will be ignored anyway.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-10234:
---
Labels: pull-request-available  (was: )

> No need to generate tailKey for transaction if there is no parallel wan 
> enabled
> ---
>
> Key: GEODE-10234
> URL: https://issues.apache.org/jira/browse/GEODE-10234
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.12.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: pull-request-available
>
> There is no need to generate a tailKey, if there is no parallel wan enabled. 
> However, currently every operation on a partitioned region would generate 
> such key and will be ignored anyway.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)