[jira] [Commented] (GEODE-6588) Cleanup internal use of generics and other static analyzer warnings [PERMANENT]

2022-04-12 Thread ASF subversion and git services (Jira) 


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

ASF subversion and git services commented on GEODE-6588:


Commit cf39ace35fb946ffeb9866e4942680506339ed9d in geode's branch 
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cf39ace35f ]

GEODE-6588: Cleanup missing @Deprecated (#7545)

Adds missing @Deprecated to all symbols with Javadoc tag @deprecated.

> Cleanup internal use of generics and other static analyzer warnings 
> [PERMANENT]
> ---
>
> Key: GEODE-6588
> URL: https://issues.apache.org/jira/browse/GEODE-6588
> Project: Geode
>  Issue Type: Task
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 8h 40m
>  Remaining Estimate: 0h
>
> Use generics where possible.
> Cleanup other static analyzer issues along the way.
> Generally make the IntelliJ analyzer gutter less cluttered.



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

[jira] [Commented] (GEODE-10227) Remove Redundant Calls to sendRequestForChunkedResponse

2022-04-12 Thread ASF GitHub Bot (Jira) 


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

ASF GitHub Bot commented on GEODE-10227:


pivotal-jbarrett commented on code in PR #957:
URL: https://github.com/apache/geode-native/pull/957#discussion_r848917389


##
cppcache/src/TcrEndpoint.cpp:
##
@@ -754,42 +754,36 @@ GfErrType TcrEndpoint::sendRequestConn(const TcrMessage& 
request,
   // TcrMessage * req = const_cast();
   LOGDEBUG("TcrEndpoint::sendRequestConn  = %p", m_baseDM);
   if (m_baseDM != nullptr) m_baseDM->beforeSendingRequest(request, conn);
-  if (((type == TcrMessage::EXECUTE_FUNCTION ||
-type == TcrMessage::EXECUTE_REGION_FUNCTION) &&
-   (request.hasResult() & 2))) {
-conn->sendRequestForChunkedResponse(request, request.getMsgLength(), reply,
-request.getTimeout(),
-reply.getTimeout());
-  } else if (type == TcrMessage::REGISTER_INTEREST_LIST ||
- type == TcrMessage::REGISTER_INTEREST ||
- type == TcrMessage::QUERY ||
- type == TcrMessage::QUERY_WITH_PARAMETERS ||
- type == TcrMessage::GET_ALL_70 ||
- type == TcrMessage::GET_ALL_WITH_CALLBACK ||
- type == TcrMessage::PUTALL ||
- type == TcrMessage::PUT_ALL_WITH_CALLBACK ||
- type == TcrMessage::REMOVE_ALL ||
- ((type == TcrMessage::EXECUTE_FUNCTION ||
-   type == TcrMessage::EXECUTE_REGION_FUNCTION) &&
-  (request.hasResult() & 2)) ||
- type ==
- TcrMessage::EXECUTE_REGION_FUNCTION_SINGLE_HOP ||  // This is
-// kept
-// aside as
-// server
-// always
-// sends
-// chunked
-// 
response.
- type == TcrMessage::EXECUTECQ_MSG_TYPE ||
- type == TcrMessage::STOPCQ_MSG_TYPE ||
- type == TcrMessage::CLOSECQ_MSG_TYPE ||
- type == TcrMessage::KEY_SET ||
- type == TcrMessage::CLOSECLIENTCQS_MSG_TYPE ||
- type == TcrMessage::GETCQSTATS_MSG_TYPE ||
- type == TcrMessage::MONITORCQ_MSG_TYPE ||
- type == TcrMessage::EXECUTECQ_WITH_IR_MSG_TYPE ||
- type == TcrMessage::GETDURABLECQS_MSG_TYPE) {
+  if (type == TcrMessage::REGISTER_INTEREST_LIST ||
+type == TcrMessage::REGISTER_INTEREST ||
+type == TcrMessage::QUERY ||
+type == TcrMessage::QUERY_WITH_PARAMETERS ||
+type == TcrMessage::GET_ALL_70 ||
+type == TcrMessage::GET_ALL_WITH_CALLBACK ||
+type == TcrMessage::PUTALL ||
+type == TcrMessage::PUT_ALL_WITH_CALLBACK ||
+type == TcrMessage::REMOVE_ALL ||
+((type == TcrMessage::EXECUTE_FUNCTION ||
+  type == TcrMessage::EXECUTE_REGION_FUNCTION) &&
+ (request.hasResult() & 2)) ||

Review Comment:
   Wasn't there a PR that turned this into an enum or specialized methods 
rather magic numbers?



##
cppcache/src/TcrEndpoint.cpp:
##
@@ -754,42 +754,36 @@ GfErrType TcrEndpoint::sendRequestConn(const TcrMessage& 
request,
   // TcrMessage * req = const_cast();
   LOGDEBUG("TcrEndpoint::sendRequestConn  = %p", m_baseDM);
   if (m_baseDM != nullptr) m_baseDM->beforeSendingRequest(request, conn);
-  if (((type == TcrMessage::EXECUTE_FUNCTION ||
-type == TcrMessage::EXECUTE_REGION_FUNCTION) &&
-   (request.hasResult() & 2))) {
-conn->sendRequestForChunkedResponse(request, request.getMsgLength(), reply,
-request.getTimeout(),
-reply.getTimeout());
-  } else if (type == TcrMessage::REGISTER_INTEREST_LIST ||
- type == TcrMessage::REGISTER_INTEREST ||
- type == TcrMessage::QUERY ||
- type == TcrMessage::QUERY_WITH_PARAMETERS ||
- type == TcrMessage::GET_ALL_70 ||
- type == TcrMessage::GET_ALL_WITH_CALLBACK ||
- type == TcrMessage::PUTALL ||
- type == TcrMessage::PUT_ALL_WITH_CALLBACK ||
- type == TcrMessage::REMOVE_ALL ||
- ((type == TcrMessage::EXECUTE_FUNCTION ||
-   type == TcrMessage::EXECUTE_REGION_FUNCTION) &&
-  (request.hasResult() & 2)) ||
- type ==
- TcrMessage::EXECUTE_REGION_FUNCTION_SINGLE_HOP ||  // This is
-// kept
-

[jira] [Resolved] (GEODE-10222) Null memberID in GII of persistent region with concurrent region destroy causes AssertionError

2022-04-12 Thread Donal Evans (Jira) 


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

Donal Evans resolved GEODE-10222.
-
Fix Version/s: 1.15.0
   Resolution: Fixed

> Null memberID in GII of persistent region with concurrent region destroy 
> causes AssertionError
> --
>
> Key: GEODE-10222
> URL: https://issues.apache.org/jira/browse/GEODE-10222
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> The below stack trace was observed while concurrent region creates and 
> destroys were being performed on a persistent replicated region:
> {noformat}
> java.lang.AssertionError: Member id should not be null for persistent version 
> tags
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.internal.cache.versions.DiskVersionTag.replaceNullIDs(DiskVersionTag.java:47)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:975)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1312)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:214)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2858)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:197)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:190)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
>   at Remote Member 'localhost(server2:13075):41003' in 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at Remote Member 'localhost(server2:13075):41003' in 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doHighPriorityThread(ClusterOperationExecutors.java:402)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
>   at Remote Member 'localhost(server2:13075):41003' in 
> java.lang.Thread.run(Thread.java:748)
>   at 
> org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:90)
>   at 
> org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:562)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1249)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3002)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2986){noformat}
> The {{AssertionError}} thrown by {{DiskVersionTag.replaceNullIDs()}} is not 
> handled by any of the calling methods, which leads to the GII failing without 
> attempting to retry, and does not decrement the getInitialImagesInProgress 
> stat.



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

[jira] [Commented] (GEODE-10222) Null memberID in GII of persistent region with concurrent region destroy causes AssertionError

2022-04-12 Thread ASF subversion and git services (Jira) 


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

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

Commit b2c1b09b2d1434169cda35436b598e03f8701d9e in geode's branch 
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b2c1b09b2d ]

GEODE-10222: Handle null memberID in GII (#7569)

 - Instead of throwing from DiskVersionTag.replaceNullIDs() if memberID
 is null, check if the memberID is null after calling  replaceNullIDs() in
 InitialImageOperation.processChunk() and then return false if it is
 - Add debug log to record if this has occurred
 - Add unit test for the new behaviour

Authored-by: Donal Evans 



> Null memberID in GII of persistent region with concurrent region destroy 
> causes AssertionError
> --
>
> Key: GEODE-10222
> URL: https://issues.apache.org/jira/browse/GEODE-10222
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Labels: blocks-1.15.0, pull-request-available
>
> The below stack trace was observed while concurrent region creates and 
> destroys were being performed on a persistent replicated region:
> {noformat}
> java.lang.AssertionError: Member id should not be null for persistent version 
> tags
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.internal.cache.versions.DiskVersionTag.replaceNullIDs(DiskVersionTag.java:47)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:975)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1312)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:214)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2858)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:197)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:190)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
>   at Remote Member 'localhost(server2:13075):41003' in 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at Remote Member 'localhost(server2:13075):41003' in 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doHighPriorityThread(ClusterOperationExecutors.java:402)
>   at Remote Member 'localhost(server2:13075):41003' in 
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
>   at Remote Member 'localhost(server2:13075):41003' in 
> java.lang.Thread.run(Thread.java:748)
>   at 
> org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:90)
>   at 
> org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:562)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1249)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3002)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2986){noformat}
> The {{AssertionError}} thrown by {{DiskVersionTag.replaceNullIDs()}} is not 
> handled by any of the calling methods, which leads to the GII failing without 
> attempting to retry, and does not decrement the getInitialImagesInProgress 
> stat.



--
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

2022-04-12 Thread 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: blocks-1.15.0 pull-request-available  (was: pull-request-available)

> 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: blocks-1.15.0, 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)

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

2022-04-12 Thread Eric Shu (Jira) 


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

Eric Shu resolved GEODE-10234.
--
Fix Version/s: 1.15.0
   Resolution: Fixed

> 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: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> 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] [Commented] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled

2022-04-12 Thread ASF subversion and git services (Jira) 


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

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

Commit 8b5ff7c03d39f8c908eb9d9ff8fb02282987cdc3 in geode's branch 
refs/heads/develop from Eric Shu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8b5ff7c03d ]

GEODE-10234: Do not generate tailKey if parallel wan not enabled. (#7583)



> 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)

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

2022-04-12 Thread Juan Ramos (Jira) 


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

Juan Ramos resolved GEODE-10230.

Fix Version/s: 1.15.0
   Resolution: Fixed

> 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
> Fix For: 1.15.0
>
>
> 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] [Commented] (GEODE-10230) Support for PDX Update and Delete Endpoints in Management REST API

2022-04-12 Thread ASF subversion and git services (Jira) 


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

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

Commit 223c5d8bdd58064422d411952352874f0ec6bbdf in geode's branch 
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=223c5d8bdd ]

GEODE-10230: PDX UPDATE/DELETE in Mgmt REST API (#7578)

Add update (HTTP put) and delete (HTTP DELETE) operations support for
PDX in the cluster management REST API service.

- Add and update unit and integration tests.
- Keep old update behaviour (NotImplementedException thrown) for cache
  configurations other than PDX.

> 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] [Assigned] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover

2022-04-12 Thread Mark Hanson (Jira) 


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

Mark Hanson reassigned GEODE-10228:
---

Assignee: Mark Hanson

> 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
>Assignee: Mark Hanson
>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] [Resolved] (GEODE-10059) CI: WANRollingUpgradeNewSenderProcessOldEvent > oldEventShouldBeProcessedAtNewSender[from_v1.13.7] FAILED

2022-04-12 Thread Anilkumar Gingade (Jira) 


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

Anilkumar Gingade resolved GEODE-10059.
---
Resolution: Cannot Reproduce

The issue did not reproduce in successive runs.

> CI: WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtNewSender[from_v1.13.7] FAILED
> -
>
> Key: GEODE-10059
> URL: https://issues.apache.org/jira/browse/GEODE-10059
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.8
>Reporter: Kristen
>Priority: Major
>  Labels: needsTriage
>
>  
> {code:java}
> > Task :geode-wan:upgradeTest
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtNewSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtNewSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtNewSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
>    

[jira] [Commented] (GEODE-10059) CI: WANRollingUpgradeNewSenderProcessOldEvent > oldEventShouldBeProcessedAtNewSender[from_v1.13.7] FAILED

2022-04-12 Thread Anilkumar Gingade (Jira) 


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

Anilkumar Gingade commented on GEODE-10059:
---

Sounds related to environment issue. The test has passed in successive runs. 
Closing this for now; we will re-open once this surfaces again.

> CI: WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtNewSender[from_v1.13.7] FAILED
> -
>
> Key: GEODE-10059
> URL: https://issues.apache.org/jira/browse/GEODE-10059
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.8
>Reporter: Kristen
>Priority: Major
>  Labels: needsTriage
>
>  
> {code:java}
> > Task :geode-wan:upgradeTest
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtNewSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtNewSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host 
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on 
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > 
> oldEventShouldBeProcessedAtNewSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run 

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

2022-04-12 Thread ASF subversion and git services (Jira) 


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

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

Commit ce975a0c1c08fa8975f6c4507a4988799a15b6ef in geode's branch 
refs/heads/develop from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ce975a0c1c ]

GEODE-10232: reformat list for more reliable rendering (#7581)



> 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] [Updated] (GEODE-10235) deployLargeSetOfJars fails with jdk 17

2022-04-12 Thread ASF GitHub Bot (Jira) 


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

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

> deployLargeSetOfJars fails with jdk 17
> --
>
> Key: GEODE-10235
> URL: https://issues.apache.org/jira/browse/GEODE-10235
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: Java17, pull-request-available
>
> The failure is caused by "--max-heap" not working with jdk 17.
> {noformat}
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by 
> [7a912a18dd64e4c9: 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=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
>  
> expected: 0
>  but was: 1
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at 
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> 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)
> {noformat}



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

[jira] [Assigned] (GEODE-10235) deployLargeSetOfJars fails with jdk 17

2022-04-12 Thread Darrel Schneider (Jira) 


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

Darrel Schneider reassigned GEODE-10235:


Assignee: Darrel Schneider

> deployLargeSetOfJars fails with jdk 17
> --
>
> Key: GEODE-10235
> URL: https://issues.apache.org/jira/browse/GEODE-10235
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: Java17
>
> The failure is caused by "--max-heap" not working with jdk 17.
> {noformat}
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by 
> [7a912a18dd64e4c9: 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=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
>  
> expected: 0
>  but was: 1
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at 
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> 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)
> {noformat}



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

[jira] [Updated] (GEODE-10235) deployLargeSetOfJars fails with jdk 17

2022-04-12 Thread Darrel Schneider (Jira) 


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

Darrel Schneider updated GEODE-10235:
-
Labels: Java17  (was: jdk17)

> deployLargeSetOfJars fails with jdk 17
> --
>
> Key: GEODE-10235
> URL: https://issues.apache.org/jira/browse/GEODE-10235
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Darrel Schneider
>Priority: Major
>  Labels: Java17
>
> The failure is caused by "--max-heap" not working with jdk 17.
> {noformat}
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by 
> [7a912a18dd64e4c9: 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=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
>  
> expected: 0
>  but was: 1
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at 
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> 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)
> {noformat}



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

[jira] [Updated] (GEODE-10235) deployLargeSetOfJars fails with jdk 17

2022-04-12 Thread Darrel Schneider (Jira) 


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

Darrel Schneider updated GEODE-10235:
-
Labels: jdk17  (was: )

> deployLargeSetOfJars fails with jdk 17
> --
>
> Key: GEODE-10235
> URL: https://issues.apache.org/jira/browse/GEODE-10235
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Darrel Schneider
>Priority: Major
>  Labels: jdk17
>
> The failure is caused by "--max-heap" not working with jdk 17.
> {noformat}
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by 
> [7a912a18dd64e4c9: 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=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
>  
> expected: 0
>  but was: 1
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at 
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> 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)
> {noformat}



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

[jira] [Created] (GEODE-10235) deployLargeSetOfJars fails with jdk 17

2022-04-12 Thread Darrel Schneider (Jira) 
Darrel Schneider created GEODE-10235:


 Summary: deployLargeSetOfJars fails with jdk 17
 Key: GEODE-10235
 URL: https://issues.apache.org/jira/browse/GEODE-10235
 Project: Geode
  Issue Type: Improvement
  Components: core
Reporter: Darrel Schneider


The failure is caused by "--max-heap" not working with jdk 17.
{noformat}
DeployWithLargeJarTest > deployLargeSetOfJars FAILED
org.opentest4j.AssertionFailedError: [Exit value from process started by 
[7a912a18dd64e4c9: 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=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
 
expected: 0
 but was: 1
at 
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at 
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
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)
{noformat}




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

[jira] [Resolved] (GEODE-10204) Add unit test cases for SizeableByteArrayList

2022-04-12 Thread Bala Tripura Sundari Kaza Venkata (Jira) 


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

Bala Tripura Sundari Kaza Venkata resolved GEODE-10204.
---
Fix Version/s: 1.15.0
   Resolution: Fixed

> Add unit test cases for SizeableByteArrayList
> -
>
> Key: GEODE-10204
> URL: https://issues.apache.org/jira/browse/GEODE-10204
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Assignee: Bala Tripura Sundari Kaza Venkata
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> For example, {{clearSublist()}} was added for LTRIM support and needs unit 
> tests. Any public method that does not just call the {{super()}} method on 
> {{LinkedList}} should have coverage.



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

[jira] [Commented] (GEODE-10204) Add unit test cases for SizeableByteArrayList

2022-04-12 Thread ASF subversion and git services (Jira) 


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

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

Commit 79659680035bc81f52b08e4e9a2e6ca6d33d4aed in geode's branch 
refs/heads/develop from Bala Kaza Venkata
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7965968003 ]

GEODE-10204: Add Test Coverage for SizeableByteArrayList (#7566)



> Add unit test cases for SizeableByteArrayList
> -
>
> Key: GEODE-10204
> URL: https://issues.apache.org/jira/browse/GEODE-10204
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Assignee: Bala Tripura Sundari Kaza Venkata
>Priority: Major
>  Labels: pull-request-available
>
> For example, {{clearSublist()}} was added for LTRIM support and needs unit 
> tests. Any public method that does not just call the {{super()}} method on 
> {{LinkedList}} should have coverage.



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

[jira] [Resolved] (GEODE-9955) Implement RPUSHX

2022-04-12 Thread Kristen (Jira) 


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

Kristen resolved GEODE-9955.

Fix Version/s: 1.15.0
   Resolution: Fixed

> Implement RPUSHX
> 
>
> Key: GEODE-9955
> URL: https://issues.apache.org/jira/browse/GEODE-9955
> Project: Geode
>  Issue Type: New Feature
>  Components: redis
>Reporter: Wayne
>Assignee: Kristen
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Implement the [RPUSHX|https://redis.io/commands/rpushx] command.
>  
> +Acceptance Criteria+
> The command has been implemented along with appropriate unit and system tests.
>  
> The command has been tested using the redis-cli tool and verified against 
> native redis.
>  



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

[jira] [Resolved] (GEODE-10171) AbstractRedisData version being incremented for no-op operations can lead to delta not being applied on secondary

2022-04-12 Thread Kristen (Jira) 


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

Kristen resolved GEODE-10171.
-
Fix Version/s: 1.15.0
   Resolution: Fixed

> AbstractRedisData version being incremented for no-op operations can lead to 
> delta not being applied on secondary
> -
>
> Key: GEODE-10171
> URL: https://issues.apache.org/jira/browse/GEODE-10171
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Kristen
>Priority: Major
>  Labels: pull-request-available, redis-triage
> Fix For: 1.15.0
>
>
> For SADD, which may or may not modify the data in the region depending on 
> whether the member being added is already present in the set, the version in 
> AbstractRedisData is updated regardless of whether a Delta is sent to the 
> secondary. This can lead to the version on the primary wrapping around to be 
> equal to the version on the secondary, which means that if a delta is sent, 
> it will not be applied on the secondary, leading to potential data loss.
> Below is a test to show this behaviour:
> {code:java}
> @Test
> public void deltaVersionOnPrimary_shouldNotUpdate_ifNoDeltaSent() {
>   String originalMember = "fixedMemberName";
>   String key = clusterStartUp.getKeyOnServer("tag", 1);
>   
>   // Version of primary = 0
>   // Version of secondary = 0
>   jedis.sadd(key, originalMember);
>   // No changes are made to the set, since adding an already existing member 
> doesn't modify it
>   // Version of primary wraps around back to -1
>   // Version of secondary doesn't change because we don't send a delta
>   for (int i = 0; i < 255; ++i) {
> jedis.sadd(key, originalMember);
>   }
>   String newMember = "aNewMemberName";
>   // Version of primary = 0
>   // Version of secondary = 0, delta is not applied
>   jedis.sadd(key, newMember);
>   assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember, 
> newMember);
>   clusterStartUp.crashVM(1); // kill primary server
>   assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember, 
> newMember);
> } {code}
> The example here uses SADD, but potentially, any command that can be a no-op 
> and uses a versioned Delta is at risk of hitting this. All commands should be 
> checked to ensure they're not vulnerable to this bug.



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

[jira] [Commented] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with ServerConnectivityException : Pool unexpected socket timed out on client

2022-04-12 Thread Geode Integration (Jira) 


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

Geode Integration commented on GEODE-8616:
--

Seen on support/1.12 in [distributed-test-openjdk8 
#59|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk8/builds/59]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0374/test-results/distributedTest/1649758624/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0374/test-artifacts/1649758624/distributedtestfiles-openjdk8-1.12.10-build.0374.tgz].

> ClientServerCacheOperationDUnitTest > 
> largeObjectPutWithReadTimeoutThrowsException fails with 
> ServerConnectivityException : Pool unexpected socket timed out on client
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.12.1, 1.13.7, 1.14.3, 1.15.0
>Reporter: Donal Evans
>Assignee: Nabarun Nag
>Priority: Major
>  Labels: GeodeOperationAPI, flaky-test, pull-request-available, 
> testing
> Fix For: 1.15.0
>
> Attachments: hansonm-findfailures-11-10-2021-23-52-38-logs.tgz, 
> hansonm-findfailures-11-10-2021-23-52-45-logs.tgz
>
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest > 
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
>  in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at 
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool 
> unexpected socket timed out on client connection=Pooled Connection to 
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not 
> connect after 1 attempts
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at 
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at 
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at 
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at 
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at 
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at 
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at 
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at 
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.



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

[jira] [Commented] (GEODE-10147) CI Failure: [ benchmark-with-ssl ] FAILURE: Build failed with an exception while trying to run ssl benchmarks

2022-04-12 Thread Geode Integration (Jira) 


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

Geode Integration commented on GEODE-10147:
---

Seen in [benchmark-base 
#277|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/277].

> CI Failure: [ benchmark-with-ssl ]  FAILURE: Build failed with an exception 
> while trying to run ssl benchmarks
> --
>
> Key: GEODE-10147
> URL: https://issues.apache.org/jira/browse/GEODE-10147
> Project: Geode
>  Issue Type: Bug
>  Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
>
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> P2pPartitionedPutBenchmark > run() FAILED
> net.schmizz.sshj.transport.TransportException: Connection reset
> at 
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at 
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at 
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.copyFromNode(SshInfrastructure.java:185)
> at 
> org.apache.geode.perftest.jvms.RemoteJVMs.copyResults(RemoteJVMs.java:87)
> at 
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:112)
> at 
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
> at 
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark.run(P2pPartitionedPutBenchmark.java:52)
> Caused by:
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:186)
> at java.net.SocketInputStream.read(SocketInputStream.java:140)
> at java.net.SocketInputStream.read(SocketInputStream.java:200)
> at 
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
> at 
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> ... 8 more
> 4 tests completed, 1 failed
> This is ITERATION 2 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> ReplicatedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.io.UncheckedIOException: 
> net.schmizz.sshj.transport.TransportException: Server closed connection 
> during identification exchange
> at 
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at 
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at 
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1739)
> at 
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at 
> java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at 
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by:
> java.io.UncheckedIOException: 
> net.schmizz.sshj.transport.TransportException: Server closed connection 
> during identification exchange
> at 
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> at 
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
> ... 6 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed 
> connection during identification exchange
> at 
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at 
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at 
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at 
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> ... 7 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed 
> connection during identification exchange
>    

[jira] [Resolved] (GEODE-10157) Add unit tests for all Delta classes in package org.apache.geode.redis.internal.data

2022-04-12 Thread Ray Ingles (Jira) 


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

Ray Ingles resolved GEODE-10157.

Fix Version/s: 1.15.0
   Resolution: Fixed

Tests for all Redis delta types.

> Add unit tests for all Delta classes in package 
> org.apache.geode.redis.internal.data
> 
>
> Key: GEODE-10157
> URL: https://issues.apache.org/jira/browse/GEODE-10157
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Ray Ingles
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Expand on tests in 
> {{org.apache.geode.redis.internal.data.DeltaClassesJUnitTest}} for all other 
> delta-related classes in this package.



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

[jira] [Commented] (GEODE-10157) Add unit tests for all Delta classes in package org.apache.geode.redis.internal.data

2022-04-12 Thread ASF subversion and git services (Jira) 


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

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

Commit 2456b89b2600096158b7a34ae3d275b85cfc9f4d in geode's branch 
refs/heads/develop from Ray Ingles
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2456b89b26 ]

GEODE-10157: Add Radish Delta Unit Tests (#7558)

* GEODE-10157: Add Radish Delta Unit Tests

Unit tests for all the Geode-for-Redis delta types.

Co-authored-by: Ray Ingles 

> Add unit tests for all Delta classes in package 
> org.apache.geode.redis.internal.data
> 
>
> Key: GEODE-10157
> URL: https://issues.apache.org/jira/browse/GEODE-10157
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Jens Deppe
>Assignee: Ray Ingles
>Priority: Major
>  Labels: pull-request-available
>
> Expand on tests in 
> {{org.apache.geode.redis.internal.data.DeltaClassesJUnitTest}} for all other 
> delta-related classes in this package.



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

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

2022-04-12 Thread ASF GitHub Bot (Jira) 


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

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

> 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
>  Labels: pull-request-available
>
> 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)