[jira] [Commented] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188294#comment-17188294 ] ASF subversion and git services commented on GEODE-8455: Commit 304e4d5857fc7539c054713e6eaddb0e74ea01d8 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=304e4d58 ] GEODE-8455: Fix difference between create region with gw sender and a… (#5476) * GEODE-8455: Fix difference between create region with gw sender and alter region with gw sender Geode behaves differently with respect to transactions when creating a partitioned region with a parallel gateway sender to when first the partitioned region is created and then the parallel gateway sender is added by altering the region. In the first case (create region with gateway sender), when sending a transaction for the region, an event is sent to each server hosting the bucket for the data in the transaction. In the second case (create region + alter region), when sending a transaction for the region, an event is sent to every cache member and not only to those hosting the bucket for the data in the transaction. This leads to, in the servers not hosting the bucket for the data, that the events are stored in the bucketToTempQueueMap member variable of the ParallelGatewaySenderQueue. The behavior in the first case is the right one. The wrong behavior is provoked by the setting to true of the requiresNotification variable of the PartitionedRegion by the distributeUpdatedProfileOnSenderCreation method. This method should only set this variable to true in case the sender is serial as it is done when a partitioned region is initialized. * feature/GEODE-8455: Fix bug shown in dist tests and minor changes after review * GEODE-8455: Remove unused parameter from helper method in WANTestBase support test class > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188293#comment-17188293 ] ASF subversion and git services commented on GEODE-8455: Commit 304e4d5857fc7539c054713e6eaddb0e74ea01d8 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=304e4d58 ] GEODE-8455: Fix difference between create region with gw sender and a… (#5476) * GEODE-8455: Fix difference between create region with gw sender and alter region with gw sender Geode behaves differently with respect to transactions when creating a partitioned region with a parallel gateway sender to when first the partitioned region is created and then the parallel gateway sender is added by altering the region. In the first case (create region with gateway sender), when sending a transaction for the region, an event is sent to each server hosting the bucket for the data in the transaction. In the second case (create region + alter region), when sending a transaction for the region, an event is sent to every cache member and not only to those hosting the bucket for the data in the transaction. This leads to, in the servers not hosting the bucket for the data, that the events are stored in the bucketToTempQueueMap member variable of the ParallelGatewaySenderQueue. The behavior in the first case is the right one. The wrong behavior is provoked by the setting to true of the requiresNotification variable of the PartitionedRegion by the distributeUpdatedProfileOnSenderCreation method. This method should only set this variable to true in case the sender is serial as it is done when a partitioned region is initialized. * feature/GEODE-8455: Fix bug shown in dist tests and minor changes after review * GEODE-8455: Remove unused parameter from helper method in WANTestBase support test class > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188292#comment-17188292 ] ASF subversion and git services commented on GEODE-8455: Commit 304e4d5857fc7539c054713e6eaddb0e74ea01d8 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=304e4d58 ] GEODE-8455: Fix difference between create region with gw sender and a… (#5476) * GEODE-8455: Fix difference between create region with gw sender and alter region with gw sender Geode behaves differently with respect to transactions when creating a partitioned region with a parallel gateway sender to when first the partitioned region is created and then the parallel gateway sender is added by altering the region. In the first case (create region with gateway sender), when sending a transaction for the region, an event is sent to each server hosting the bucket for the data in the transaction. In the second case (create region + alter region), when sending a transaction for the region, an event is sent to every cache member and not only to those hosting the bucket for the data in the transaction. This leads to, in the servers not hosting the bucket for the data, that the events are stored in the bucketToTempQueueMap member variable of the ParallelGatewaySenderQueue. The behavior in the first case is the right one. The wrong behavior is provoked by the setting to true of the requiresNotification variable of the PartitionedRegion by the distributeUpdatedProfileOnSenderCreation method. This method should only set this variable to true in case the sender is serial as it is done when a partitioned region is initialized. * feature/GEODE-8455: Fix bug shown in dist tests and minor changes after review * GEODE-8455: Remove unused parameter from helper method in WANTestBase support test class > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188290#comment-17188290 ] ASF GitHub Bot commented on GEODE-8455: --- mkevo merged pull request #5476: URL: https://github.com/apache/geode/pull/5476 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188296#comment-17188296 ] ASF subversion and git services commented on GEODE-8455: Commit 304e4d5857fc7539c054713e6eaddb0e74ea01d8 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=304e4d58 ] GEODE-8455: Fix difference between create region with gw sender and a… (#5476) * GEODE-8455: Fix difference between create region with gw sender and alter region with gw sender Geode behaves differently with respect to transactions when creating a partitioned region with a parallel gateway sender to when first the partitioned region is created and then the parallel gateway sender is added by altering the region. In the first case (create region with gateway sender), when sending a transaction for the region, an event is sent to each server hosting the bucket for the data in the transaction. In the second case (create region + alter region), when sending a transaction for the region, an event is sent to every cache member and not only to those hosting the bucket for the data in the transaction. This leads to, in the servers not hosting the bucket for the data, that the events are stored in the bucketToTempQueueMap member variable of the ParallelGatewaySenderQueue. The behavior in the first case is the right one. The wrong behavior is provoked by the setting to true of the requiresNotification variable of the PartitionedRegion by the distributeUpdatedProfileOnSenderCreation method. This method should only set this variable to true in case the sender is serial as it is done when a partitioned region is initialized. * feature/GEODE-8455: Fix bug shown in dist tests and minor changes after review * GEODE-8455: Remove unused parameter from helper method in WANTestBase support test class > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188297#comment-17188297 ] ASF subversion and git services commented on GEODE-8455: Commit 304e4d5857fc7539c054713e6eaddb0e74ea01d8 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=304e4d58 ] GEODE-8455: Fix difference between create region with gw sender and a… (#5476) * GEODE-8455: Fix difference between create region with gw sender and alter region with gw sender Geode behaves differently with respect to transactions when creating a partitioned region with a parallel gateway sender to when first the partitioned region is created and then the parallel gateway sender is added by altering the region. In the first case (create region with gateway sender), when sending a transaction for the region, an event is sent to each server hosting the bucket for the data in the transaction. In the second case (create region + alter region), when sending a transaction for the region, an event is sent to every cache member and not only to those hosting the bucket for the data in the transaction. This leads to, in the servers not hosting the bucket for the data, that the events are stored in the bucketToTempQueueMap member variable of the ParallelGatewaySenderQueue. The behavior in the first case is the right one. The wrong behavior is provoked by the setting to true of the requiresNotification variable of the PartitionedRegion by the distributeUpdatedProfileOnSenderCreation method. This method should only set this variable to true in case the sender is serial as it is done when a partitioned region is initialized. * feature/GEODE-8455: Fix bug shown in dist tests and minor changes after review * GEODE-8455: Remove unused parameter from helper method in WANTestBase support test class > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188299#comment-17188299 ] ASF subversion and git services commented on GEODE-8455: Commit 304e4d5857fc7539c054713e6eaddb0e74ea01d8 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=304e4d58 ] GEODE-8455: Fix difference between create region with gw sender and a… (#5476) * GEODE-8455: Fix difference between create region with gw sender and alter region with gw sender Geode behaves differently with respect to transactions when creating a partitioned region with a parallel gateway sender to when first the partitioned region is created and then the parallel gateway sender is added by altering the region. In the first case (create region with gateway sender), when sending a transaction for the region, an event is sent to each server hosting the bucket for the data in the transaction. In the second case (create region + alter region), when sending a transaction for the region, an event is sent to every cache member and not only to those hosting the bucket for the data in the transaction. This leads to, in the servers not hosting the bucket for the data, that the events are stored in the bucketToTempQueueMap member variable of the ParallelGatewaySenderQueue. The behavior in the first case is the right one. The wrong behavior is provoked by the setting to true of the requiresNotification variable of the PartitionedRegion by the distributeUpdatedProfileOnSenderCreation method. This method should only set this variable to true in case the sender is serial as it is done when a partitioned region is initialized. * feature/GEODE-8455: Fix bug shown in dist tests and minor changes after review * GEODE-8455: Remove unused parameter from helper method in WANTestBase support test class > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188295#comment-17188295 ] ASF subversion and git services commented on GEODE-8455: Commit 304e4d5857fc7539c054713e6eaddb0e74ea01d8 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=304e4d58 ] GEODE-8455: Fix difference between create region with gw sender and a… (#5476) * GEODE-8455: Fix difference between create region with gw sender and alter region with gw sender Geode behaves differently with respect to transactions when creating a partitioned region with a parallel gateway sender to when first the partitioned region is created and then the parallel gateway sender is added by altering the region. In the first case (create region with gateway sender), when sending a transaction for the region, an event is sent to each server hosting the bucket for the data in the transaction. In the second case (create region + alter region), when sending a transaction for the region, an event is sent to every cache member and not only to those hosting the bucket for the data in the transaction. This leads to, in the servers not hosting the bucket for the data, that the events are stored in the bucketToTempQueueMap member variable of the ParallelGatewaySenderQueue. The behavior in the first case is the right one. The wrong behavior is provoked by the setting to true of the requiresNotification variable of the PartitionedRegion by the distributeUpdatedProfileOnSenderCreation method. This method should only set this variable to true in case the sender is serial as it is done when a partitioned region is initialized. * feature/GEODE-8455: Fix bug shown in dist tests and minor changes after review * GEODE-8455: Remove unused parameter from helper method in WANTestBase support test class > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188298#comment-17188298 ] ASF subversion and git services commented on GEODE-8455: Commit 304e4d5857fc7539c054713e6eaddb0e74ea01d8 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=304e4d58 ] GEODE-8455: Fix difference between create region with gw sender and a… (#5476) * GEODE-8455: Fix difference between create region with gw sender and alter region with gw sender Geode behaves differently with respect to transactions when creating a partitioned region with a parallel gateway sender to when first the partitioned region is created and then the parallel gateway sender is added by altering the region. In the first case (create region with gateway sender), when sending a transaction for the region, an event is sent to each server hosting the bucket for the data in the transaction. In the second case (create region + alter region), when sending a transaction for the region, an event is sent to every cache member and not only to those hosting the bucket for the data in the transaction. This leads to, in the servers not hosting the bucket for the data, that the events are stored in the bucketToTempQueueMap member variable of the ParallelGatewaySenderQueue. The behavior in the first case is the right one. The wrong behavior is provoked by the setting to true of the requiresNotification variable of the PartitionedRegion by the distributeUpdatedProfileOnSenderCreation method. This method should only set this variable to true in case the sender is serial as it is done when a partitioned region is initialized. * feature/GEODE-8455: Fix bug shown in dist tests and minor changes after review * GEODE-8455: Remove unused parameter from helper method in WANTestBase support test class > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8402) Move the Dockerfile to use Debian instead of Alpine
[ https://issues.apache.org/jira/browse/GEODE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188400#comment-17188400 ] Brent Driskill commented on GEODE-8402: --- Yes, that would resolve this issue. > Move the Dockerfile to use Debian instead of Alpine > --- > > Key: GEODE-8402 > URL: https://issues.apache.org/jira/browse/GEODE-8402 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Brent Driskill >Priority: Major > > OpenJDK dropped support for Alpine last May due to the incompatibility issues > between musl and glibc. See commit: > [https://github.com/docker-library/openjdk/commit/3eb0351b208d739fac35345c85e3c6237c2114ec#diff-17b0a72d5a10e24142544a9dbc8effcb] > > Geode is still pointed at the alpine version which has not received any > updates in a year: > [https://github.com/apache/geode/blob/develop/docker/Dockerfile]. This has > lead to the Java version missing the security patches for the last year. > > The FROM should be migrated to "openjdk:8-jre-slim" and the relevant > installation steps switched to support Debian. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8333) Fix PUBSUB hang
[ https://issues.apache.org/jira/browse/GEODE-8333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8333. Fix Version/s: 1.14.0 Resolution: Fixed > Fix PUBSUB hang > --- > > Key: GEODE-8333 > URL: https://issues.apache.org/jira/browse/GEODE-8333 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > PUBSUB hangs with concurrent publishers and subscribers on multiple servers. > The initial fix is being reverted because it caused a bug in which responses > to clients could now be out of order. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8467) server fails to notify of a ForcedDisconnect and fails to tear down the cache
[
https://issues.apache.org/jira/browse/GEODE-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188506#comment-17188506
]
ASF GitHub Bot commented on GEODE-8467:
---
bschuchardt merged pull request #5490:
URL: https://github.com/apache/geode/pull/5490
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> server fails to notify of a ForcedDisconnect and fails to tear down the cache
> -
>
> Key: GEODE-8467
> URL: https://issues.apache.org/jira/browse/GEODE-8467
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> A test having auto-reconnect enabled failed while restarting a server and
> hung. The restarting server was building its cache when it was kicked out of
> the cluster due to very high load on the test machine. Membership initiated
> a forced-disconnect
> {noformat}
> [fatal 2020/08/22 00:51:04.508 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> Membership service failure: Member isn't responding to heartbeat requests
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2012)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:688)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1331)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1267)
> {noformat}
>
> and then logged that it was generating a description of the cache
> {noformat}
> [info 2020/08/22 00:51:05.933 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> generating XML to rebuild the cache after reconnect completes {noformat}
>
> but it never logged completion of this step and never forked a thread to tear
> down the cache. Any exception thrown by XML generation would have been
> caught by JGroups code, which logs the problem at a WARNING level. We have
> JGroups logging set to FATAL level so you wouldn't see the issue.
> We need to add exception handling around XML generation and, if detected,
> disable reconnect attempts and have the server shut down.
> The bug isn't easy to hit. I've run the test that failed over 5000 times
> without encountering it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8467) server fails to notify of a ForcedDisconnect and fails to tear down the cache
[
https://issues.apache.org/jira/browse/GEODE-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188507#comment-17188507
]
ASF subversion and git services commented on GEODE-8467:
Commit e402ed35102a4a885ad24a1052216b0542672bc7 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e402ed3 ]
GEODE-8467: server fails to notify of a ForcedDisconnect and fails to tear down
the cache (#5490)
Catch exceptions that occur during XML generation and disable auto
reconnect.
Ensure that the DisconnectThread is launched by placing it in a
"finally" block.
> server fails to notify of a ForcedDisconnect and fails to tear down the cache
> -
>
> Key: GEODE-8467
> URL: https://issues.apache.org/jira/browse/GEODE-8467
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> A test having auto-reconnect enabled failed while restarting a server and
> hung. The restarting server was building its cache when it was kicked out of
> the cluster due to very high load on the test machine. Membership initiated
> a forced-disconnect
> {noformat}
> [fatal 2020/08/22 00:51:04.508 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> Membership service failure: Member isn't responding to heartbeat requests
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2012)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:688)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1331)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1267)
> {noformat}
>
> and then logged that it was generating a description of the cache
> {noformat}
> [info 2020/08/22 00:51:05.933 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> generating XML to rebuild the cache after reconnect completes {noformat}
>
> but it never logged completion of this step and never forked a thread to tear
> down the cache. Any exception thrown by XML generation would have been
> caught by JGroups code, which logs the problem at a WARNING level. We have
> JGroups logging set to FATAL level so you wouldn't see the issue.
> We need to add exception handling around XML generation and, if detected,
> disable reconnect attempts and have the server shut down.
> The bug isn't easy to hit. I've run the test that failed over 5000 times
> without encountering it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[ https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt updated GEODE-8349: -- Labels: no-release-note pull-request-available (was: pull-request-available) > reinstate use of SSLSocket for cluster communication > > > Key: GEODE-8349 > URL: https://issues.apache.org/jira/browse/GEODE-8349 > Project: Geode > Issue Type: Bug > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: no-release-note, pull-request-available > > We've found problems with "new IO"'s SSLEngine with respect to support for > TLSV1. We've also seen anomalous performance using that secure > communications mechanism. The introduction of the use of the "new IO" > SSLEngine was originally to 1) reduce code complexity in the > org.apache.geode.internal.tcp package and 2) to set the stage for its use in > client/server communications so that selectors could be used in c/s > communications. > This ticket aims to reintroduce the use of SSLSocket in cluster > communications without restoring the old, poorly tested SSL code paths. The > new implementation should have as good or better performance than the > previous"old IO" implementation and the more recent "new IO" SSLEngine > implementation as well. This should be apparent in the CI benchmark jobs. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[ https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt resolved GEODE-8349. --- Resolution: Won't Fix We've decided to put this effort on the shelf. > reinstate use of SSLSocket for cluster communication > > > Key: GEODE-8349 > URL: https://issues.apache.org/jira/browse/GEODE-8349 > Project: Geode > Issue Type: Bug > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > > We've found problems with "new IO"'s SSLEngine with respect to support for > TLSV1. We've also seen anomalous performance using that secure > communications mechanism. The introduction of the use of the "new IO" > SSLEngine was originally to 1) reduce code complexity in the > org.apache.geode.internal.tcp package and 2) to set the stage for its use in > client/server communications so that selectors could be used in c/s > communications. > This ticket aims to reintroduce the use of SSLSocket in cluster > communications without restoring the old, poorly tested SSL code paths. The > new implementation should have as good or better performance than the > previous"old IO" implementation and the more recent "new IO" SSLEngine > implementation as well. This should be apparent in the CI benchmark jobs. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[ https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt closed GEODE-8349. - > reinstate use of SSLSocket for cluster communication > > > Key: GEODE-8349 > URL: https://issues.apache.org/jira/browse/GEODE-8349 > Project: Geode > Issue Type: Bug > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: no-release-note, pull-request-available > > We've found problems with "new IO"'s SSLEngine with respect to support for > TLSV1. We've also seen anomalous performance using that secure > communications mechanism. The introduction of the use of the "new IO" > SSLEngine was originally to 1) reduce code complexity in the > org.apache.geode.internal.tcp package and 2) to set the stage for its use in > client/server communications so that selectors could be used in c/s > communications. > This ticket aims to reintroduce the use of SSLSocket in cluster > communications without restoring the old, poorly tested SSL code paths. The > new implementation should have as good or better performance than the > previous"old IO" implementation and the more recent "new IO" SSLEngine > implementation as well. This should be apparent in the CI benchmark jobs. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8349) reinstate use of SSLSocket for cluster communication
[ https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188517#comment-17188517 ] ASF GitHub Bot commented on GEODE-8349: --- bschuchardt closed pull request #5363: URL: https://github.com/apache/geode/pull/5363 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > reinstate use of SSLSocket for cluster communication > > > Key: GEODE-8349 > URL: https://issues.apache.org/jira/browse/GEODE-8349 > Project: Geode > Issue Type: Bug > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: no-release-note, pull-request-available > > We've found problems with "new IO"'s SSLEngine with respect to support for > TLSV1. We've also seen anomalous performance using that secure > communications mechanism. The introduction of the use of the "new IO" > SSLEngine was originally to 1) reduce code complexity in the > org.apache.geode.internal.tcp package and 2) to set the stage for its use in > client/server communications so that selectors could be used in c/s > communications. > This ticket aims to reintroduce the use of SSLSocket in cluster > communications without restoring the old, poorly tested SSL code paths. The > new implementation should have as good or better performance than the > previous"old IO" implementation and the more recent "new IO" SSLEngine > implementation as well. This should be apparent in the CI benchmark jobs. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8456) upgrade Shiro to 1.6.0
[ https://issues.apache.org/jira/browse/GEODE-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188579#comment-17188579 ] ASF subversion and git services commented on GEODE-8456: Commit 2412c88550d97afc2be2f088983424e5f087313d in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2412c88 ] GEODE-8456: bump Shiro to 1.6.0 (#5477) (cherry picked from commit 06174302b2c255fa6da8572fe7444df5dd1b2767) > upgrade Shiro to 1.6.0 > -- > > Key: GEODE-8456 > URL: https://issues.apache.org/jira/browse/GEODE-8456 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.13.0, 1.14.0 > > > Our current Shiro version (1.5.3) is below the recommended version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8456) upgrade Shiro to 1.6.0
[ https://issues.apache.org/jira/browse/GEODE-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8456: Fix Version/s: 1.13.0 > upgrade Shiro to 1.6.0 > -- > > Key: GEODE-8456 > URL: https://issues.apache.org/jira/browse/GEODE-8456 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.13.0, 1.14.0 > > > Our current Shiro version (1.5.3) is below the recommended version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8475) Resolve a potential dead lock in ParallelGatewaySenderQueue
[ https://issues.apache.org/jira/browse/GEODE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188638#comment-17188638 ] Xiaojian Zhou commented on GEODE-8475: -- This fix is actually a patch to GEODE-5748. Gaining the writeLock of lockFailedInitialImageWriteLock (lock-B) was introduced there. But at that time, we did not realized this potential deadlock and our tests did not find the issue either. This patch can be applied back to old release up to 1.8 if necessary. > Resolve a potential dead lock in ParallelGatewaySenderQueue > > > Key: GEODE-8475 > URL: https://issues.apache.org/jira/browse/GEODE-8475 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When brq is created but encountered a failed GII, enqueue to it could have a > potential deadlock: > Thread-1: > ParallelGatewaySenderQueue.put() will get a > brq.getInitializationLock().readLock().lock() (lock-A’s read lock). Then > during the put operation, it will try to call lockWhenRegionIsInitializing() > to get failedInitialImageLock.readLock().lock (lock-B’s read lock) > Thread-2: > PRDS.createBucketRegion() will trigger GII but failed. So it will call > cleanUpAfterFailedGII(), where it will call lockFailedInitialImageWriteLock > () to get lock-B’s write lock first. Then call > BucketRegionQueue.clearEntries(). > It will call getInitializationLock().writeLock().lock() (lock-A’s write lock). > To fix it, we need to let thread-1 to get failedInitialImageLock.readLock() > (lock-B) before requesting lock-A. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8475) Resolve a potential dead lock in ParallelGatewaySenderQueue
[
https://issues.apache.org/jira/browse/GEODE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188644#comment-17188644
]
ASF GitHub Bot commented on GEODE-8475:
---
agingade commented on a change in pull request #5492:
URL: https://github.com/apache/geode/pull/5492#discussion_r481287853
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
##
@@ -755,12 +755,16 @@ public boolean put(Object object) throws
InterruptedException, CacheException {
bucketFullPath, brq);
}
if (brq != null) {
+boolean intializingLocked = brq.lockWhenRegionIsInitializing();
Review comment:
Can we add unit tests to make sure failed Initialization lock is held
during put.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
##
@@ -755,12 +755,16 @@ public boolean put(Object object) throws
InterruptedException, CacheException {
bucketFullPath, brq);
}
if (brq != null) {
+boolean intializingLocked = brq.lockWhenRegionIsInitializing();
brq.getInitializationLock().readLock().lock();
try {
putIntoBucketRegionQueue(brq, key, value);
putDone = true;
} finally {
brq.getInitializationLock().readLock().unlock();
+ if (intializingLocked) {
Review comment:
I assume we don't have to worry about the above unlock code throwing any
exception...
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Resolve a potential dead lock in ParallelGatewaySenderQueue
>
>
> Key: GEODE-8475
> URL: https://issues.apache.org/jira/browse/GEODE-8475
> Project: Geode
> Issue Type: Improvement
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> When brq is created but encountered a failed GII, enqueue to it could have a
> potential deadlock:
> Thread-1:
> ParallelGatewaySenderQueue.put() will get a
> brq.getInitializationLock().readLock().lock() (lock-A’s read lock). Then
> during the put operation, it will try to call lockWhenRegionIsInitializing()
> to get failedInitialImageLock.readLock().lock (lock-B’s read lock)
> Thread-2:
> PRDS.createBucketRegion() will trigger GII but failed. So it will call
> cleanUpAfterFailedGII(), where it will call lockFailedInitialImageWriteLock
> () to get lock-B’s write lock first. Then call
> BucketRegionQueue.clearEntries().
> It will call getInitializationLock().writeLock().lock() (lock-A’s write lock).
> To fix it, we need to let thread-1 to get failedInitialImageLock.readLock()
> (lock-B) before requesting lock-A.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8476) Windows: AlterRuntimeCommandDistributedTest. alterLogDiskSpaceLimitOnMember_OK(false) [1] failed
Mark Hanson created GEODE-8476: -- Summary: Windows: AlterRuntimeCommandDistributedTest. alterLogDiskSpaceLimitOnMember_OK(false) [1] failed Key: GEODE-8476 URL: https://issues.apache.org/jira/browse/GEODE-8476 Project: Geode Issue Type: Bug Components: core Affects Versions: 1.14.0 Reporter: Mark Hanson java.lang.AssertionError: Suspicious strings were written to the log during this run. Fix the strings or use IgnoredException.addIgnoredException to ignore. --- Found suspect string in log4j at line 778 [fatal 2020/09/01 03:02:19.031 GMT tid=192] Unknown handshake reply code: 0 messageLength: 89 =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0313/test-results/distributedTest/1598931752/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test report artifacts from this job are available at: http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0313/test-artifacts/1598931752/windows-gfshdistributedtest-OpenJDK11-1.14.0-build.0313.tgz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8477) getMembersNotShuttingDown() doesn't use consistent set of shutdown members
Bill Burcham created GEODE-8477:
---
Summary: getMembersNotShuttingDown() doesn't use consistent set of
shutdown members
Key: GEODE-8477
URL: https://issues.apache.org/jira/browse/GEODE-8477
Project: Geode
Issue Type: Bug
Components: membership
Affects Versions: 1.12.0, 1.13.0, 1.14.0
Reporter: Bill Burcham
{{GMSMembership.getMembersNotShuttingDown()}} correctly accesses {{latestView}}
under the protection of the read lock {{latestViewReadLock}} associated with
the read-write lock {{latestViewLock}} ✓
However that method also accesses the {{shutdownMembers}} collection, a
{{(Bounded)LinkedHashMap}}. That class does not provide concurrency protection.
Furthermore {{shutdownMembers}} is not read/written under the protection of
{{latestViewLock}} ✕
The result is that in this method, {{shutdownMembers}} may be corrupt and its
contents may be arbitrarily stale.
One solution is to put all reads and writes of {{shutdownMembers}} under the
protection of the same read-write lock as {{latestView}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8477) getMembersNotShuttingDown() doesn't use consistent set of shutdown members
[
https://issues.apache.org/jira/browse/GEODE-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8477:
Description:
{{GMSMembership.getMembersNotShuttingDown()}} correctly accesses {{latestView}}
under the protection of the read lock {{latestViewReadLock}} associated with
the read-write lock {{latestViewLock}} ✓
However that method also accesses the {{shutdownMembers}} collection, a
{{(Bounded)LinkedHashMap}}. That class does not provide concurrency protection.
Furthermore {{shutdownMembers}} is not read/written under the protection of
{{latestViewLock}} ✕
The result is that in this method, {{shutdownMembers}} may be corrupt and its
contents may be arbitrarily stale.
One solution is to put all reads and writes of {{shutdownMembers}} under the
protection of the same read-write lock as {{latestView}}. If we do this we can
eliminate existing synchronization on {{shutdownMembers}}.
was:
{{GMSMembership.getMembersNotShuttingDown()}} correctly accesses {{latestView}}
under the protection of the read lock {{latestViewReadLock}} associated with
the read-write lock {{latestViewLock}} ✓
However that method also accesses the {{shutdownMembers}} collection, a
{{(Bounded)LinkedHashMap}}. That class does not provide concurrency protection.
Furthermore {{shutdownMembers}} is not read/written under the protection of
{{latestViewLock}} ✕
The result is that in this method, {{shutdownMembers}} may be corrupt and its
contents may be arbitrarily stale.
One solution is to put all reads and writes of {{shutdownMembers}} under the
protection of the same read-write lock as {{latestView}}
> getMembersNotShuttingDown() doesn't use consistent set of shutdown members
> --
>
> Key: GEODE-8477
> URL: https://issues.apache.org/jira/browse/GEODE-8477
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {{GMSMembership.getMembersNotShuttingDown()}} correctly accesses
> {{latestView}} under the protection of the read lock {{latestViewReadLock}}
> associated with the read-write lock {{latestViewLock}} ✓
> However that method also accesses the {{shutdownMembers}} collection, a
> {{(Bounded)LinkedHashMap}}. That class does not provide concurrency
> protection. Furthermore {{shutdownMembers}} is not read/written under the
> protection of {{latestViewLock}} ✕
> The result is that in this method, {{shutdownMembers}} may be corrupt and its
> contents may be arbitrarily stale.
> One solution is to put all reads and writes of {{shutdownMembers}} under the
> protection of the same read-write lock as {{latestView}}. If we do this we
> can eliminate existing synchronization on {{shutdownMembers}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8477) getMembersNotShuttingDown() doesn't use consistent set of shutdown members
[
https://issues.apache.org/jira/browse/GEODE-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8477:
Description:
{{GMSMembership.getMembersNotShuttingDown()}} correctly accesses {{latestView}}
under the protection of the read lock {{latestViewReadLock}} associated with
the read-write lock {{latestViewLock}} ✓
However that method also accesses the {{shutdownMembers}} collection, a
{{(Bounded)LinkedHashMap}}. That class does not provide concurrency protection.
Furthermore {{shutdownMembers}} is not read/written consistently under the
protection of any synchronization ✕
The result is that in this method, {{shutdownMembers}} may be corrupt and its
contents may be arbitrarily stale.
One solution is to put all reads and writes of {{shutdownMembers}} under the
protection of the same read-write lock as {{latestView}}. If we do this we can
eliminate existing synchronization on {{shutdownMembers}}.
was:
{{GMSMembership.getMembersNotShuttingDown()}} correctly accesses {{latestView}}
under the protection of the read lock {{latestViewReadLock}} associated with
the read-write lock {{latestViewLock}} ✓
However that method also accesses the {{shutdownMembers}} collection, a
{{(Bounded)LinkedHashMap}}. That class does not provide concurrency protection.
Furthermore {{shutdownMembers}} is not read/written under the protection of
{{latestViewLock}} ✕
The result is that in this method, {{shutdownMembers}} may be corrupt and its
contents may be arbitrarily stale.
One solution is to put all reads and writes of {{shutdownMembers}} under the
protection of the same read-write lock as {{latestView}}. If we do this we can
eliminate existing synchronization on {{shutdownMembers}}.
> getMembersNotShuttingDown() doesn't use consistent set of shutdown members
> --
>
> Key: GEODE-8477
> URL: https://issues.apache.org/jira/browse/GEODE-8477
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {{GMSMembership.getMembersNotShuttingDown()}} correctly accesses
> {{latestView}} under the protection of the read lock {{latestViewReadLock}}
> associated with the read-write lock {{latestViewLock}} ✓
> However that method also accesses the {{shutdownMembers}} collection, a
> {{(Bounded)LinkedHashMap}}. That class does not provide concurrency
> protection. Furthermore {{shutdownMembers}} is not read/written consistently
> under the protection of any synchronization ✕
> The result is that in this method, {{shutdownMembers}} may be corrupt and its
> contents may be arbitrarily stale.
> One solution is to put all reads and writes of {{shutdownMembers}} under the
> protection of the same read-write lock as {{latestView}}. If we do this we
> can eliminate existing synchronization on {{shutdownMembers}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8477) getMembersNotShuttingDown() doesn't use consistent set of shutdown members
[
https://issues.apache.org/jira/browse/GEODE-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8477:
Description:
{{GMSMembership.getMembersNotShuttingDown()}} correctly accesses {{latestView}}
under the protection of the read lock {{latestViewReadLock}} associated with
the read-write lock {{latestViewLock}} ✓
However that method also accesses the {{shutdownMembers}} collection, a
{{(Bounded)LinkedHashMap}}. That class does not provide concurrency protection.
Furthermore {{shutdownMembers}} is not read/written consistently under the
protection of any synchronization ✕
The result is that in this method, {{shutdownMembers}} may be corrupt and its
contents may be arbitrarily stale.
One solution is to put all reads and writes of {{shutdownMembers}} under the
protection of the same read-write lock as {{latestView}}. If we do this we can
eliminate existing synchronization on {{shutdownMembers}} in
{{shutdownMessageReceived()}}.
was:
{{GMSMembership.getMembersNotShuttingDown()}} correctly accesses {{latestView}}
under the protection of the read lock {{latestViewReadLock}} associated with
the read-write lock {{latestViewLock}} ✓
However that method also accesses the {{shutdownMembers}} collection, a
{{(Bounded)LinkedHashMap}}. That class does not provide concurrency protection.
Furthermore {{shutdownMembers}} is not read/written consistently under the
protection of any synchronization ✕
The result is that in this method, {{shutdownMembers}} may be corrupt and its
contents may be arbitrarily stale.
One solution is to put all reads and writes of {{shutdownMembers}} under the
protection of the same read-write lock as {{latestView}}. If we do this we can
eliminate existing synchronization on {{shutdownMembers}}.
> getMembersNotShuttingDown() doesn't use consistent set of shutdown members
> --
>
> Key: GEODE-8477
> URL: https://issues.apache.org/jira/browse/GEODE-8477
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {{GMSMembership.getMembersNotShuttingDown()}} correctly accesses
> {{latestView}} under the protection of the read lock {{latestViewReadLock}}
> associated with the read-write lock {{latestViewLock}} ✓
> However that method also accesses the {{shutdownMembers}} collection, a
> {{(Bounded)LinkedHashMap}}. That class does not provide concurrency
> protection. Furthermore {{shutdownMembers}} is not read/written consistently
> under the protection of any synchronization ✕
> The result is that in this method, {{shutdownMembers}} may be corrupt and its
> contents may be arbitrarily stale.
> One solution is to put all reads and writes of {{shutdownMembers}} under the
> protection of the same read-write lock as {{latestView}}. If we do this we
> can eliminate existing synchronization on {{shutdownMembers}} in
> {{shutdownMessageReceived()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8467) server fails to notify of a ForcedDisconnect and fails to tear down the cache
[
https://issues.apache.org/jira/browse/GEODE-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188717#comment-17188717
]
ASF subversion and git services commented on GEODE-8467:
Commit 8a66bc3b376f391b7f387c74b9b5246d72882178 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8a66bc3 ]
GEODE-8467: server fails to notify of a ForcedDisconnect and fails to tear down
the cache (#5490)
Catch exceptions that occur during XML generation and disable auto
reconnect.
Ensure that the DisconnectThread is launched by placing it in a
"finally" block.
(cherry picked from commit e402ed35102a4a885ad24a1052216b0542672bc7)
> server fails to notify of a ForcedDisconnect and fails to tear down the cache
> -
>
> Key: GEODE-8467
> URL: https://issues.apache.org/jira/browse/GEODE-8467
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> A test having auto-reconnect enabled failed while restarting a server and
> hung. The restarting server was building its cache when it was kicked out of
> the cluster due to very high load on the test machine. Membership initiated
> a forced-disconnect
> {noformat}
> [fatal 2020/08/22 00:51:04.508 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> Membership service failure: Member isn't responding to heartbeat requests
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2012)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:688)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1331)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1267)
> {noformat}
>
> and then logged that it was generating a description of the cache
> {noformat}
> [info 2020/08/22 00:51:05.933 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> generating XML to rebuild the cache after reconnect completes {noformat}
>
> but it never logged completion of this step and never forked a thread to tear
> down the cache. Any exception thrown by XML generation would have been
> caught by JGroups code, which logs the problem at a WARNING level. We have
> JGroups logging set to FATAL level so you wouldn't see the issue.
> We need to add exception handling around XML generation and, if detected,
> disable reconnect attempts and have the server shut down.
> The bug isn't easy to hit. I've run the test that failed over 5000 times
> without encountering it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8404) Simplify port reservation in tests
[
https://issues.apache.org/jira/browse/GEODE-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188719#comment-17188719
]
ASF GitHub Bot commented on GEODE-8404:
---
demery-pivotal closed pull request #5471:
URL: https://github.com/apache/geode/pull/5471
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Simplify port reservation in tests
> --
>
> Key: GEODE-8404
> URL: https://issues.apache.org/jira/browse/GEODE-8404
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> {{AvailablePort}}, {{AvailablePortHelper}}, and {{UniquePortSupplier}}
> implement a variety of complex mechanisms to reserve ports for use in the
> product and in tests.
> This complexity is unnecessary in cases where the chosen port need not be
> restricted to a specified range. Most of the ports allocated for tests have
> no such range restrictions, and so can rely on the OS to allocate available
> ports simply, directly, and efficiently.
> In particular:
> {{AvailablePort}} implements two methods to reserve only those ports that are
> a multiple of a given modulus. These methods are implemented badly, so that
> each call can render many ports unavailable before finding one that satisfies
> the constraints. These methods are not used in Geode or in tests, so I will
> remove them rather than fixing them.
> {{AvailablePortHelper}} (used only in tests) attempts to reduce the number of
> unavailable ports it tests by partitioning the available ports among VMS, and
> by storing state in a global static variable. In almost all cases, this
> mechanism can be replaced by letting the OS choose available ports.
> {{UniquePortSupplier}} (used only in tests) remembers every port it allocates
> and will not allocate the same port twice. This mechanism has the fatal
> limitation that uniqueness is guaranteed only among uses of the same
> {{UniquePortSupplier}} instance. This mechanism can be replaced by letting
> the OS choose available ports.
> {{AvailablePort.Keeper}} retains a port reservation until the caller is ready
> to bind to the port. {{Keeper}}'s use within {{AvailablePort}} is
> unnecessary. Its use in tests is limited to only a few instances. I will try
> to make those instances unnecessary. If it turns out that some tests require
> holding onto a reservation beyond its "natural" ({{TIME_WAIT}}) duration, I
> will move {{Keeper}} to into the {{geode-junit}} module, near (or inside)
> {{AvailablePortHelper}}.
> Once this complexity is reduced to its necessary minimum, I will refactor
> these classes (safely, with additional tests to cover currently untested
> features) to remove duplication and make the remaining code clearer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8404) Simplify port reservation in tests
[
https://issues.apache.org/jira/browse/GEODE-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8404:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> Simplify port reservation in tests
> --
>
> Key: GEODE-8404
> URL: https://issues.apache.org/jira/browse/GEODE-8404
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {{AvailablePort}}, {{AvailablePortHelper}}, and {{UniquePortSupplier}}
> implement a variety of complex mechanisms to reserve ports for use in the
> product and in tests.
> This complexity is unnecessary in cases where the chosen port need not be
> restricted to a specified range. Most of the ports allocated for tests have
> no such range restrictions, and so can rely on the OS to allocate available
> ports simply, directly, and efficiently.
> In particular:
> {{AvailablePort}} implements two methods to reserve only those ports that are
> a multiple of a given modulus. These methods are implemented badly, so that
> each call can render many ports unavailable before finding one that satisfies
> the constraints. These methods are not used in Geode or in tests, so I will
> remove them rather than fixing them.
> {{AvailablePortHelper}} (used only in tests) attempts to reduce the number of
> unavailable ports it tests by partitioning the available ports among VMS, and
> by storing state in a global static variable. In almost all cases, this
> mechanism can be replaced by letting the OS choose available ports.
> {{UniquePortSupplier}} (used only in tests) remembers every port it allocates
> and will not allocate the same port twice. This mechanism has the fatal
> limitation that uniqueness is guaranteed only among uses of the same
> {{UniquePortSupplier}} instance. This mechanism can be replaced by letting
> the OS choose available ports.
> {{AvailablePort.Keeper}} retains a port reservation until the caller is ready
> to bind to the port. {{Keeper}}'s use within {{AvailablePort}} is
> unnecessary. Its use in tests is limited to only a few instances. I will try
> to make those instances unnecessary. If it turns out that some tests require
> holding onto a reservation beyond its "natural" ({{TIME_WAIT}}) duration, I
> will move {{Keeper}} to into the {{geode-junit}} module, near (or inside)
> {{AvailablePortHelper}}.
> Once this complexity is reduced to its necessary minimum, I will refactor
> these classes (safely, with additional tests to cover currently untested
> features) to remove duplication and make the remaining code clearer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8467) server fails to notify of a ForcedDisconnect and fails to tear down the cache
[
https://issues.apache.org/jira/browse/GEODE-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-8467.
---
Fix Version/s: 1.13.0
Resolution: Fixed
Bugnote: This resolves an issue with auto-reconnect that could leave a server
in a hung state.
> server fails to notify of a ForcedDisconnect and fails to tear down the cache
> -
>
> Key: GEODE-8467
> URL: https://issues.apache.org/jira/browse/GEODE-8467
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.0
>
>
> A test having auto-reconnect enabled failed while restarting a server and
> hung. The restarting server was building its cache when it was kicked out of
> the cluster due to very high load on the test machine. Membership initiated
> a forced-disconnect
> {noformat}
> [fatal 2020/08/22 00:51:04.508 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> Membership service failure: Member isn't responding to heartbeat requests
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2012)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:688)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1331)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1267)
> {noformat}
>
> and then logged that it was generating a description of the cache
> {noformat}
> [info 2020/08/22 00:51:05.933 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> generating XML to rebuild the cache after reconnect completes {noformat}
>
> but it never logged completion of this step and never forked a thread to tear
> down the cache. Any exception thrown by XML generation would have been
> caught by JGroups code, which logs the problem at a WARNING level. We have
> JGroups logging set to FATAL level so you wouldn't see the issue.
> We need to add exception handling around XML generation and, if detected,
> disable reconnect attempts and have the server shut down.
> The bug isn't easy to hit. I've run the test that failed over 5000 times
> without encountering it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8404) Simplify port reservation in tests
[
https://issues.apache.org/jira/browse/GEODE-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188721#comment-17188721
]
ASF GitHub Bot commented on GEODE-8404:
---
demery-pivotal opened a new pull request #5493:
URL: https://github.com/apache/geode/pull/5493
Removed the following unused methods:
- getRandomAvailableTCPPortRange(int)
- getRandomAvailableTCPPorts(int,bool)
- getRandomAvailableTCPPortRangeKeepers(int)
- getRandomAvailableTCPPortRangeKeepers(int,bool)
Removed two methods that used an ineffective, incorrect calculation to
try to distribute ports evenly across VMs:
- getRandomAvailablePortForDUnitSite()
- getRandomAvailableTCPPortsForDUnitSite()
These methods attempted to distribute ports by using the VM id as a
modulus. The intention was something like this (assuming 5 VMs):
VM 1 would get ports 20001, 20006, 20011, 20016, ...
VM 2 would get ports 20002, 20007, 20012, 20017, ...
VM 3 would get ports 20003, 20008, 20013, 20018, ...
VM 4 would get ports 20004, 20009, 20014, 20019, ...
VM 5 would get ports 2, 20005, 20010, 20015, ...
But the actual calculation distributed ports like this:
VM 1: 2, 20001, 20002, 20003, 20004, ...
VM 2: 2, 20002, 20004, 20006, 20008, ...
VM 3: 20001, 20004, 20007, 20010, 20013, ...
VM 4: 2, 20004, 20008, 20012, 20016, ...
VM 5: 2, 20005, 20010, 20015, 20020, ...
... with lots of potential port collisions from one VM to another.
The few uses of these methods were replaced by calls to existing methods
getRandomAvailableTCPPort() and getRandomAvailableTCPPorts(), which
offer a more reliable method of distributing ports.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Simplify port reservation in tests
> --
>
> Key: GEODE-8404
> URL: https://issues.apache.org/jira/browse/GEODE-8404
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {{AvailablePort}}, {{AvailablePortHelper}}, and {{UniquePortSupplier}}
> implement a variety of complex mechanisms to reserve ports for use in the
> product and in tests.
> This complexity is unnecessary in cases where the chosen port need not be
> restricted to a specified range. Most of the ports allocated for tests have
> no such range restrictions, and so can rely on the OS to allocate available
> ports simply, directly, and efficiently.
> In particular:
> {{AvailablePort}} implements two methods to reserve only those ports that are
> a multiple of a given modulus. These methods are implemented badly, so that
> each call can render many ports unavailable before finding one that satisfies
> the constraints. These methods are not used in Geode or in tests, so I will
> remove them rather than fixing them.
> {{AvailablePortHelper}} (used only in tests) attempts to reduce the number of
> unavailable ports it tests by partitioning the available ports among VMS, and
> by storing state in a global static variable. In almost all cases, this
> mechanism can be replaced by letting the OS choose available ports.
> {{UniquePortSupplier}} (used only in tests) remembers every port it allocates
> and will not allocate the same port twice. This mechanism has the fatal
> limitation that uniqueness is guaranteed only among uses of the same
> {{UniquePortSupplier}} ins
[jira] [Updated] (GEODE-8469) Enforce no-missing-variable-declarations
[ https://issues.apache.org/jira/browse/GEODE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8469: -- Labels: pull-request-available (was: ) > Enforce no-missing-variable-declarations > > > Key: GEODE-8469 > URL: https://issues.apache.org/jira/browse/GEODE-8469 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Given I compile the code without exempting no-missing-variable-declarations > Then it should compile > Note - was marked as a todo -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8469) Enforce no-missing-variable-declarations
[
https://issues.apache.org/jira/browse/GEODE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188745#comment-17188745
]
ASF GitHub Bot commented on GEODE-8469:
---
pivotal-jbarrett commented on a change in pull request #645:
URL: https://github.com/apache/geode-native/pull/645#discussion_r481354457
##
File path: cppcache/benchmark/GeodeLoggingBM.cpp
##
@@ -106,13 +106,13 @@ void GeodeLogToFile(benchmark::State& state) {
}
}
-auto LogStringsToConsole = GeodeLogToConsole;
-auto LogIntsToConsole = GeodeLogToConsole;
-auto LogComboToConsole = GeodeLogToConsole;
+static auto LogStringsToConsole = GeodeLogToConsole;
Review comment:
`const` also?
##
File path: tests/cpp/security/XmlAuthzCredentialGenerator.hpp
##
@@ -55,7 +55,7 @@ const opCodeList::value_type QArr[] = {OP_QUERY,
OP_REGISTER_CQ};
const stringList::value_type QRArr[] = {"Portfolios", "Positions"};
-const char* PRiUsnm = "%s%d";
+static const char* PRiUsnm = "%s%d";
Review comment:
`constexpr` work here?
##
File path: cppcache/integration-test/fw_dunit.cpp
##
@@ -71,10 +71,10 @@ using
apache::geode::client::testframework::BBNamingContextServer;
#define __DUNIT_NO_MAIN__
#include "fw_dunit.hpp"
-ACE_TCHAR *g_programName = nullptr;
-uint32_t g_coordinatorPid = 0;
+static ACE_TCHAR *g_programName = nullptr;
Review comment:
Yuck! I attempted to take on this beast and gave up on trying to clean
up the old tests. Good job!
##
File path: cppcache/test/CacheXmlParserTest.cpp
##
@@ -99,7 +99,7 @@ std::string valid_cache_config_body = R"(
)";
-std::string invalid_cache_config_body = R"(
+static std::string invalid_cache_config_body = R"(
Review comment:
`const` ?
##
File path: cppcache/src/PdxFieldType.cpp
##
@@ -31,7 +31,7 @@ namespace apache {
namespace geode {
namespace client {
-int32_t fixedTypeSizes[] = {
+static int32_t fixedTypeSizes[] = {
Review comment:
`const` and use the `const` naming convention here?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Enforce no-missing-variable-declarations
>
>
> Key: GEODE-8469
> URL: https://issues.apache.org/jira/browse/GEODE-8469
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Oleske
>Priority: Major
>
> Given I compile the code without exempting no-missing-variable-declarations
> Then it should compile
> Note - was marked as a todo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8478) Exceptions that occur while logging threshold exceeded alerts cause the GatewaySender to shutdown
[
https://issues.apache.org/jira/browse/GEODE-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby reassigned GEODE-8478:
--
Assignee: Barrett Oglesby
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> -
>
> Key: GEODE-8478
> URL: https://issues.apache.org/jira/browse/GEODE-8478
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> If an exception occurs while logging threshold exceeded alerts, a fatal
> message and warnings like these are logged:
> {noformat}
> [fatal 2020/07/27 05:23:05.911 EDT GatewaySender_mySender_5> tid=0x17487] Stopping the processor because the
> following exception occurred while processing a batch:
> java.lang.IllegalArgumentException: The Object passed in should not be null.
> ...
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getValueAsString(GatewaySenderEventImpl.java:615)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.handleSuccessBatchAck(AbstractGatewaySenderEventProcessor.java:1053)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:636)
> [warn 2020/07/27 05:23:05.927 EDT GatewaySender_mySender_5> tid=0xdb] Pool unexpected Socket closed
> connection=Pooled Connection to xxx:12028: Connection[DESTROYED]). Server
> unreachable: could not connect after 1 attempts
> [warn 2020/07/27 05:23:20.916 EDT GatewaySender_mySender_5> tid=0x17487] AckReaderThread ignored cancellation
> [warn 2020/07/27 05:23:20.921 EDT GatewaySender_mySender_5> tid=0x17487] Destroying GatewayEventDispatcher with
> actively queued data.
> {noformat}
> The catch block in {{GatewaySenderEventRemoteDispatcher$AckReaderThread.run}}
> stops the processor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8478) Exceptions that occur while logging threshold exceeded alerts cause the GatewaySender to shutdown
Barrett Oglesby created GEODE-8478:
--
Summary: Exceptions that occur while logging threshold exceeded
alerts cause the GatewaySender to shutdown
Key: GEODE-8478
URL: https://issues.apache.org/jira/browse/GEODE-8478
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Barrett Oglesby
Exceptions that occur while logging threshold exceeded alerts cause the
GatewaySender to shutdown
If an exception occurs while logging threshold exceeded alerts, a fatal message
and warnings like these are logged:
{noformat}
[fatal 2020/07/27 05:23:05.911 EDT tid=0x17487] Stopping the processor because the
following exception occurred while processing a batch:
java.lang.IllegalArgumentException: The Object passed in should not be null.
...
at
org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getValueAsString(GatewaySenderEventImpl.java:615)
at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.handleSuccessBatchAck(AbstractGatewaySenderEventProcessor.java:1053)
at
org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:636)
[warn 2020/07/27 05:23:05.927 EDT tid=0xdb] Pool unexpected Socket closed
connection=Pooled Connection to xxx:12028: Connection[DESTROYED]). Server
unreachable: could not connect after 1 attempts
[warn 2020/07/27 05:23:20.916 EDT tid=0x17487] AckReaderThread ignored cancellation
[warn 2020/07/27 05:23:20.921 EDT tid=0x17487] Destroying GatewayEventDispatcher with
actively queued data.
{noformat}
The catch block in {{GatewaySenderEventRemoteDispatcher$AckReaderThread.run}}
stops the processor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8478) Exceptions that occur while logging threshold exceeded alerts cause the GatewaySender to shutdown
[
https://issues.apache.org/jira/browse/GEODE-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8478:
--
Labels: pull-request-available (was: )
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> -
>
> Key: GEODE-8478
> URL: https://issues.apache.org/jira/browse/GEODE-8478
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> If an exception occurs while logging threshold exceeded alerts, a fatal
> message and warnings like these are logged:
> {noformat}
> [fatal 2020/07/27 05:23:05.911 EDT GatewaySender_mySender_5> tid=0x17487] Stopping the processor because the
> following exception occurred while processing a batch:
> java.lang.IllegalArgumentException: The Object passed in should not be null.
> ...
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getValueAsString(GatewaySenderEventImpl.java:615)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.handleSuccessBatchAck(AbstractGatewaySenderEventProcessor.java:1053)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:636)
> [warn 2020/07/27 05:23:05.927 EDT GatewaySender_mySender_5> tid=0xdb] Pool unexpected Socket closed
> connection=Pooled Connection to xxx:12028: Connection[DESTROYED]). Server
> unreachable: could not connect after 1 attempts
> [warn 2020/07/27 05:23:20.916 EDT GatewaySender_mySender_5> tid=0x17487] AckReaderThread ignored cancellation
> [warn 2020/07/27 05:23:20.921 EDT GatewaySender_mySender_5> tid=0x17487] Destroying GatewayEventDispatcher with
> actively queued data.
> {noformat}
> The catch block in {{GatewaySenderEventRemoteDispatcher$AckReaderThread.run}}
> stops the processor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8478) Exceptions that occur while logging threshold exceeded alerts cause the GatewaySender to shutdown
[
https://issues.apache.org/jira/browse/GEODE-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188767#comment-17188767
]
ASF GitHub Bot commented on GEODE-8478:
---
boglesby opened a new pull request #5494:
URL: https://github.com/apache/geode/pull/5494
…handle exceptions
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> -
>
> Key: GEODE-8478
> URL: https://issues.apache.org/jira/browse/GEODE-8478
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> If an exception occurs while logging threshold exceeded alerts, a fatal
> message and warnings like these are logged:
> {noformat}
> [fatal 2020/07/27 05:23:05.911 EDT GatewaySender_mySender_5> tid=0x17487] Stopping the processor because the
> following exception occurred while processing a batch:
> java.lang.IllegalArgumentException: The Object passed in should not be null.
> ...
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getValueAsString(GatewaySenderEventImpl.java:615)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.handleSuccessBatchAck(AbstractGatewaySenderEventProcessor.java:1053)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:636)
> [warn 2020/07/27 05:23:05.927 EDT GatewaySender_mySender_5> tid=0xdb] Pool unexpected Socket closed
> connection=Pooled Connection to xxx:12028: Connection[DESTROYED]). Server
> unreachable: could not connect after 1 attempts
> [warn 2020/07/27 05:23:20.916 EDT GatewaySender_mySender_5> tid=0x17487] AckReaderThread ignored cancellation
> [warn 2020/07/27 05:23:20.921 EDT GatewaySender_mySender_5> tid=0x17487] Destroying GatewayEventDispatcher with
> actively queued data.
> {noformat}
> The catch block in {{GatewaySenderEventRemoteDispatcher$AckReaderThread.run}}
> stops the processor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8478) Exceptions that occur while logging threshold exceeded alerts cause the GatewaySender to shutdown
[
https://issues.apache.org/jira/browse/GEODE-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188768#comment-17188768
]
ASF subversion and git services commented on GEODE-8478:
Commit 3683f708ae75445e6feb177d766e86c8c828c5ea in geode's branch
refs/heads/feature/GEODE-8478 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3683f70 ]
GEODE-8478: Refactored logThresholdExceededAlerts and modified it to handle
exceptions
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> -
>
> Key: GEODE-8478
> URL: https://issues.apache.org/jira/browse/GEODE-8478
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> If an exception occurs while logging threshold exceeded alerts, a fatal
> message and warnings like these are logged:
> {noformat}
> [fatal 2020/07/27 05:23:05.911 EDT GatewaySender_mySender_5> tid=0x17487] Stopping the processor because the
> following exception occurred while processing a batch:
> java.lang.IllegalArgumentException: The Object passed in should not be null.
> ...
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getValueAsString(GatewaySenderEventImpl.java:615)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.handleSuccessBatchAck(AbstractGatewaySenderEventProcessor.java:1053)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:636)
> [warn 2020/07/27 05:23:05.927 EDT GatewaySender_mySender_5> tid=0xdb] Pool unexpected Socket closed
> connection=Pooled Connection to xxx:12028: Connection[DESTROYED]). Server
> unreachable: could not connect after 1 attempts
> [warn 2020/07/27 05:23:20.916 EDT GatewaySender_mySender_5> tid=0x17487] AckReaderThread ignored cancellation
> [warn 2020/07/27 05:23:20.921 EDT GatewaySender_mySender_5> tid=0x17487] Destroying GatewayEventDispatcher with
> actively queued data.
> {noformat}
> The catch block in {{GatewaySenderEventRemoteDispatcher$AckReaderThread.run}}
> stops the processor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8478) Exceptions that occur while logging threshold exceeded alerts cause the GatewaySender to shutdown
[
https://issues.apache.org/jira/browse/GEODE-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188771#comment-17188771
]
ASF subversion and git services commented on GEODE-8478:
Commit 3683f708ae75445e6feb177d766e86c8c828c5ea in geode's branch
refs/heads/feature/GEODE-8478 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3683f70 ]
GEODE-8478: Refactored logThresholdExceededAlerts and modified it to handle
exceptions
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> -
>
> Key: GEODE-8478
> URL: https://issues.apache.org/jira/browse/GEODE-8478
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> If an exception occurs while logging threshold exceeded alerts, a fatal
> message and warnings like these are logged:
> {noformat}
> [fatal 2020/07/27 05:23:05.911 EDT GatewaySender_mySender_5> tid=0x17487] Stopping the processor because the
> following exception occurred while processing a batch:
> java.lang.IllegalArgumentException: The Object passed in should not be null.
> ...
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getValueAsString(GatewaySenderEventImpl.java:615)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.handleSuccessBatchAck(AbstractGatewaySenderEventProcessor.java:1053)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:636)
> [warn 2020/07/27 05:23:05.927 EDT GatewaySender_mySender_5> tid=0xdb] Pool unexpected Socket closed
> connection=Pooled Connection to xxx:12028: Connection[DESTROYED]). Server
> unreachable: could not connect after 1 attempts
> [warn 2020/07/27 05:23:20.916 EDT GatewaySender_mySender_5> tid=0x17487] AckReaderThread ignored cancellation
> [warn 2020/07/27 05:23:20.921 EDT GatewaySender_mySender_5> tid=0x17487] Destroying GatewayEventDispatcher with
> actively queued data.
> {noformat}
> The catch block in {{GatewaySenderEventRemoteDispatcher$AckReaderThread.run}}
> stops the processor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8469) Enforce no-missing-variable-declarations
[ https://issues.apache.org/jira/browse/GEODE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188813#comment-17188813 ] ASF GitHub Bot commented on GEODE-8469: --- moleske commented on a change in pull request #645: URL: https://github.com/apache/geode-native/pull/645#discussion_r481420359 ## File path: cppcache/integration-test/fw_dunit.cpp ## @@ -71,10 +71,10 @@ using apache::geode::client::testframework::BBNamingContextServer; #define __DUNIT_NO_MAIN__ #include "fw_dunit.hpp" -ACE_TCHAR *g_programName = nullptr; -uint32_t g_coordinatorPid = 0; +static ACE_TCHAR *g_programName = nullptr; Review comment: I think the worst part is since I was letting the compiler tell me what was wrong rather than proactively look for places, it built only a partial percent at a time when it was building the integration-test. Thanks for the reminder on places that should be able to use `const`! Putting a link to the [`const` naming style guide](https://google.github.io/styleguide/cppguide#Constant_Names) so I don't forget This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Enforce no-missing-variable-declarations > > > Key: GEODE-8469 > URL: https://issues.apache.org/jira/browse/GEODE-8469 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Given I compile the code without exempting no-missing-variable-declarations > Then it should compile > Note - was marked as a todo -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8469) Enforce no-missing-variable-declarations
[ https://issues.apache.org/jira/browse/GEODE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188812#comment-17188812 ] ASF GitHub Bot commented on GEODE-8469: --- moleske commented on a change in pull request #645: URL: https://github.com/apache/geode-native/pull/645#discussion_r481420359 ## File path: cppcache/integration-test/fw_dunit.cpp ## @@ -71,10 +71,10 @@ using apache::geode::client::testframework::BBNamingContextServer; #define __DUNIT_NO_MAIN__ #include "fw_dunit.hpp" -ACE_TCHAR *g_programName = nullptr; -uint32_t g_coordinatorPid = 0; +static ACE_TCHAR *g_programName = nullptr; Review comment: I think the worst part is since I was letting the compiler tell me what was wrong rather than proactively look for places, I build only a partial percent at a time when it was building the integration-test. Thanks for the reminder on places that should be able to use `const`! Putting a link to the [`const` naming style guide](https://google.github.io/styleguide/cppguide#Constant_Names) so I don't forget This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Enforce no-missing-variable-declarations > > > Key: GEODE-8469 > URL: https://issues.apache.org/jira/browse/GEODE-8469 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Given I compile the code without exempting no-missing-variable-declarations > Then it should compile > Note - was marked as a todo -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8478) Exceptions that occur while logging threshold exceeded alerts cause the GatewaySender to shutdown
[
https://issues.apache.org/jira/browse/GEODE-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188843#comment-17188843
]
ASF subversion and git services commented on GEODE-8478:
Commit 0ab19ec86c5e70ab1ae852b0c6a74825bc2ccec1 in geode's branch
refs/heads/feature/GEODE-8478 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0ab19ec ]
GEODE-8478: Added try/catch around toString call in getValueAsString
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> -
>
> Key: GEODE-8478
> URL: https://issues.apache.org/jira/browse/GEODE-8478
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> Exceptions that occur while logging threshold exceeded alerts cause the
> GatewaySender to shutdown
> If an exception occurs while logging threshold exceeded alerts, a fatal
> message and warnings like these are logged:
> {noformat}
> [fatal 2020/07/27 05:23:05.911 EDT GatewaySender_mySender_5> tid=0x17487] Stopping the processor because the
> following exception occurred while processing a batch:
> java.lang.IllegalArgumentException: The Object passed in should not be null.
> ...
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getValueAsString(GatewaySenderEventImpl.java:615)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.handleSuccessBatchAck(AbstractGatewaySenderEventProcessor.java:1053)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:636)
> [warn 2020/07/27 05:23:05.927 EDT GatewaySender_mySender_5> tid=0xdb] Pool unexpected Socket closed
> connection=Pooled Connection to xxx:12028: Connection[DESTROYED]). Server
> unreachable: could not connect after 1 attempts
> [warn 2020/07/27 05:23:20.916 EDT GatewaySender_mySender_5> tid=0x17487] AckReaderThread ignored cancellation
> [warn 2020/07/27 05:23:20.921 EDT GatewaySender_mySender_5> tid=0x17487] Destroying GatewayEventDispatcher with
> actively queued data.
> {noformat}
> The catch block in {{GatewaySenderEventRemoteDispatcher$AckReaderThread.run}}
> stops the processor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-1383) LogBanner is missing from rolled log files
[ https://issues.apache.org/jira/browse/GEODE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-1383: Assignee: Kirk Lund > LogBanner is missing from rolled log files > -- > > Key: GEODE-1383 > URL: https://issues.apache.org/jira/browse/GEODE-1383 > Project: Geode > Issue Type: Bug > Components: logging >Reporter: Jens Deppe >Assignee: Kirk Lund >Priority: Major > Labels: LogBanner, observability, starter > > Please add gemfire,heap, xml configuration information to start of every log > file > We often have situations where we have difficulty establishing the > configuration or JVM startup arguments, or XML configuration without multiple > interactions with the customer, even when they've provided logs. When the > customer has rolled over enough, and we overwrite the "parent" first log, we > then lose all of that detail from startup that often proves very helpful. > If it would be easy to incorporate this startup configuration information > into the beginning of each log file as we rollover, we would always have it > and be able to be more productive debugging prod issues and ultimately have > happier users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8460) Configure sni test based on docker availablility
[ https://issues.apache.org/jira/browse/GEODE-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188866#comment-17188866 ] ASF GitHub Bot commented on GEODE-8460: --- mmartell opened a new pull request #647: URL: https://github.com/apache/geode-native/pull/647 This PR cleans up our docker based SNITests. In particular: - SNITests are now enabled during cmake configuration based on whether docker and docker-compose are installed. - SNITests have been moved to a new acceptance-test folder to keep them separated from tests which don't use docker. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Configure sni test based on docker availablility > > > Key: GEODE-8460 > URL: https://issues.apache.org/jira/browse/GEODE-8460 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Ernest Burghardt >Priority: Major > > The SNI tests require docker to be available and configured; therefore, Cmake > can be used to configure the test(s) to be enabled/disabled appropriately. > > Additionally, the tests should be moved to a new test layer as these tests > are not "integration tests" per se... "acceptance test" is a viable name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8460) Configure sni test based on docker availablility
[ https://issues.apache.org/jira/browse/GEODE-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8460: -- Labels: pull-request-available (was: ) > Configure sni test based on docker availablility > > > Key: GEODE-8460 > URL: https://issues.apache.org/jira/browse/GEODE-8460 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Labels: pull-request-available > > The SNI tests require docker to be available and configured; therefore, Cmake > can be used to configure the test(s) to be enabled/disabled appropriately. > > Additionally, the tests should be moved to a new test layer as these tests > are not "integration tests" per se... "acceptance test" is a viable name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7672) Partitioned Region clear will successfully update the OQL indexes
[ https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188868#comment-17188868 ] ASF GitHub Bot commented on GEODE-7672: --- mhansonp commented on pull request #5436: URL: https://github.com/apache/geode/pull/5436#issuecomment-685193313 I made some updates on mhansonp minorcleanup to resolve warnings. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Partitioned Region clear will successfully update the OQL indexes > - > > Key: GEODE-7672 > URL: https://issues.apache.org/jira/browse/GEODE-7672 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeCommons, pull-request-available > > Clear operations are successfully updates the OQL indexes > > Acceptance : > * Passing Dunit tests where OQL queries using indexes return correct results > after the region is cleared > * clear operation and index updates are successful when clear operation is > executed when the puts are occurring which are trying to update the OQL index. > * Unit tests to ensure that index sizes are zero after the region is cleaned > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > > analyze if these tests are needed for offheap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7672) Partitioned Region clear will successfully update the OQL indexes
[
https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188873#comment-17188873
]
ASF GitHub Bot commented on GEODE-7672:
---
mhansonp commented on a change in pull request #5436:
URL: https://github.com/apache/geode/pull/5436#discussion_r481498183
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/cache/query/partitioned/PRClearQueryIndexDUnitTest.java
##
@@ -0,0 +1,374 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.cache.query.partitioned;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.SERIALIZABLE_OBJECT_FILTER;
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.apache.geode.test.junit.rules.VMProvider.invokeInEveryMember;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.util.concurrent.Future;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.IntStream;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ServerOperationException;
+import org.apache.geode.cache.query.Index;
+import org.apache.geode.cache.query.IndexStatistics;
+import org.apache.geode.cache.query.Query;
+import org.apache.geode.cache.query.QueryService;
+import org.apache.geode.cache.query.SelectResults;
+import org.apache.geode.cache.query.data.City;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.test.dunit.AsyncInvocation;
+import org.apache.geode.test.dunit.DUnitBlackboard;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.rules.ClientCacheRule;
+import org.apache.geode.test.junit.rules.ExecutorServiceRule;
+
+public class PRClearQueryIndexDUnitTest {
+ public static final String MUMBAI_QUERY = "select * from /cities c where
c.name = 'MUMBAI'";
+ public static final String ID_10_QUERY = "select * from /cities c where c.id
= 10";
+ @ClassRule
+ public static ClusterStartupRule cluster = new ClusterStartupRule(4, true);
+
+ private static MemberVM server1;
+ private static MemberVM server2;
+
+ private static DUnitBlackboard blackboard;
+
+ @Rule
+ public ClientCacheRule clientCacheRule = new ClientCacheRule();
+
+ @Rule
+ public ExecutorServiceRule executor = ExecutorServiceRule.builder().build();
+
+ private ClientCache clientCache;
+ private Region cities;
+
+ // class test setup. set up the servers, regions and indexes on the servers
+ @BeforeClass
+ public static void beforeClass() {
+int locatorPort = ClusterStartupRule.getDUnitLocatorPort();
+server1 = cluster.startServerVM(1, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+server2 = cluster.startServerVM(2, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+
+server1.invoke(() -> {
+ Cache cache = ClusterStartupRule.getCache();
+ Region region = cache.getRegion("cities");
+ // create indexes
+ QueryService queryService = cache.getQueryService();
+ queryService.createKeyIndex("cityId", "c.id", "/cities c");
+ queryService.createIndex("cityName", "c.name", "/cities c");
+ assertThat(cache.getQueryService().getIndexes(region))
+ .extracting(Index::getName).containsExactlyInAnyOrder("cityId",
"cityName");
+});
+
+server2.invoke(() -> {
+ Cache cache = ClusterStartupRule.getCache();
+ Region region = cache.getRegion("cities");
+ assertThat(cache.getQueryService().getIndexes(region))
+ .extractin
[jira] [Commented] (GEODE-7672) Partitioned Region clear will successfully update the OQL indexes
[
https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188874#comment-17188874
]
ASF GitHub Bot commented on GEODE-7672:
---
mhansonp commented on a change in pull request #5436:
URL: https://github.com/apache/geode/pull/5436#discussion_r481498183
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/cache/query/partitioned/PRClearQueryIndexDUnitTest.java
##
@@ -0,0 +1,374 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.cache.query.partitioned;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.SERIALIZABLE_OBJECT_FILTER;
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.apache.geode.test.junit.rules.VMProvider.invokeInEveryMember;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.util.concurrent.Future;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.IntStream;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ServerOperationException;
+import org.apache.geode.cache.query.Index;
+import org.apache.geode.cache.query.IndexStatistics;
+import org.apache.geode.cache.query.Query;
+import org.apache.geode.cache.query.QueryService;
+import org.apache.geode.cache.query.SelectResults;
+import org.apache.geode.cache.query.data.City;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.test.dunit.AsyncInvocation;
+import org.apache.geode.test.dunit.DUnitBlackboard;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.rules.ClientCacheRule;
+import org.apache.geode.test.junit.rules.ExecutorServiceRule;
+
+public class PRClearQueryIndexDUnitTest {
+ public static final String MUMBAI_QUERY = "select * from /cities c where
c.name = 'MUMBAI'";
+ public static final String ID_10_QUERY = "select * from /cities c where c.id
= 10";
+ @ClassRule
+ public static ClusterStartupRule cluster = new ClusterStartupRule(4, true);
+
+ private static MemberVM server1;
+ private static MemberVM server2;
+
+ private static DUnitBlackboard blackboard;
+
+ @Rule
+ public ClientCacheRule clientCacheRule = new ClientCacheRule();
+
+ @Rule
+ public ExecutorServiceRule executor = ExecutorServiceRule.builder().build();
+
+ private ClientCache clientCache;
+ private Region cities;
+
+ // class test setup. set up the servers, regions and indexes on the servers
+ @BeforeClass
+ public static void beforeClass() {
+int locatorPort = ClusterStartupRule.getDUnitLocatorPort();
+server1 = cluster.startServerVM(1, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+server2 = cluster.startServerVM(2, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+
+server1.invoke(() -> {
+ Cache cache = ClusterStartupRule.getCache();
+ Region region = cache.getRegion("cities");
+ // create indexes
+ QueryService queryService = cache.getQueryService();
+ queryService.createKeyIndex("cityId", "c.id", "/cities c");
+ queryService.createIndex("cityName", "c.name", "/cities c");
+ assertThat(cache.getQueryService().getIndexes(region))
+ .extracting(Index::getName).containsExactlyInAnyOrder("cityId",
"cityName");
+});
+
+server2.invoke(() -> {
+ Cache cache = ClusterStartupRule.getCache();
+ Region region = cache.getRegion("cities");
+ assertThat(cache.getQueryService().getIndexes(region))
+ .extractin
[jira] [Commented] (GEODE-7672) Partitioned Region clear will successfully update the OQL indexes
[
https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188875#comment-17188875
]
ASF GitHub Bot commented on GEODE-7672:
---
mhansonp commented on a change in pull request #5436:
URL: https://github.com/apache/geode/pull/5436#discussion_r481498899
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/cache/query/partitioned/PRClearQueryIndexDUnitTest.java
##
@@ -0,0 +1,374 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.cache.query.partitioned;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.SERIALIZABLE_OBJECT_FILTER;
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.apache.geode.test.junit.rules.VMProvider.invokeInEveryMember;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.util.concurrent.Future;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.IntStream;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ServerOperationException;
+import org.apache.geode.cache.query.Index;
+import org.apache.geode.cache.query.IndexStatistics;
+import org.apache.geode.cache.query.Query;
+import org.apache.geode.cache.query.QueryService;
+import org.apache.geode.cache.query.SelectResults;
+import org.apache.geode.cache.query.data.City;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.test.dunit.AsyncInvocation;
+import org.apache.geode.test.dunit.DUnitBlackboard;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.rules.ClientCacheRule;
+import org.apache.geode.test.junit.rules.ExecutorServiceRule;
+
+public class PRClearQueryIndexDUnitTest {
+ public static final String MUMBAI_QUERY = "select * from /cities c where
c.name = 'MUMBAI'";
+ public static final String ID_10_QUERY = "select * from /cities c where c.id
= 10";
+ @ClassRule
+ public static ClusterStartupRule cluster = new ClusterStartupRule(4, true);
+
+ private static MemberVM server1;
+ private static MemberVM server2;
+
+ private static DUnitBlackboard blackboard;
+
+ @Rule
+ public ClientCacheRule clientCacheRule = new ClientCacheRule();
+
+ @Rule
+ public ExecutorServiceRule executor = ExecutorServiceRule.builder().build();
+
+ private ClientCache clientCache;
+ private Region cities;
+
+ // class test setup. set up the servers, regions and indexes on the servers
+ @BeforeClass
+ public static void beforeClass() {
+int locatorPort = ClusterStartupRule.getDUnitLocatorPort();
+server1 = cluster.startServerVM(1, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+server2 = cluster.startServerVM(2, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+
+server1.invoke(() -> {
+ Cache cache = ClusterStartupRule.getCache();
+ Region region = cache.getRegion("cities");
+ // create indexes
+ QueryService queryService = cache.getQueryService();
+ queryService.createKeyIndex("cityId", "c.id", "/cities c");
+ queryService.createIndex("cityName", "c.name", "/cities c");
+ assertThat(cache.getQueryService().getIndexes(region))
+ .extracting(Index::getName).containsExactlyInAnyOrder("cityId",
"cityName");
+});
+
+server2.invoke(() -> {
+ Cache cache = ClusterStartupRule.getCache();
+ Region region = cache.getRegion("cities");
+ assertThat(cache.getQueryService().getIndexes(region))
+ .extractin
[jira] [Commented] (GEODE-8460) Configure sni test based on docker availablility
[ https://issues.apache.org/jira/browse/GEODE-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188876#comment-17188876 ] ASF GitHub Bot commented on GEODE-8460: --- moleske commented on pull request #647: URL: https://github.com/apache/geode-native/pull/647#issuecomment-685198557 I'm excited about this! It seems like there is a new category of `acceptance-test`. Not sure when difference between integration and acceptance is (I think it is just does it need docker), but there should be an update to CONTRIBUTING.md to make sure that contributors run tests in the acceptance test directory This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Configure sni test based on docker availablility > > > Key: GEODE-8460 > URL: https://issues.apache.org/jira/browse/GEODE-8460 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Labels: pull-request-available > > The SNI tests require docker to be available and configured; therefore, Cmake > can be used to configure the test(s) to be enabled/disabled appropriately. > > Additionally, the tests should be moved to a new test layer as these tests > are not "integration tests" per se... "acceptance test" is a viable name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8460) Configure sni test based on docker availablility
[ https://issues.apache.org/jira/browse/GEODE-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188877#comment-17188877 ] ASF GitHub Bot commented on GEODE-8460: --- moleske edited a comment on pull request #647: URL: https://github.com/apache/geode-native/pull/647#issuecomment-685198557 I'm excited about this! It seems like there is a new category of `acceptance-test`. There should be an update to CONTRIBUTING.md to make sure that contributors run tests in the acceptance test directory This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Configure sni test based on docker availablility > > > Key: GEODE-8460 > URL: https://issues.apache.org/jira/browse/GEODE-8460 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Labels: pull-request-available > > The SNI tests require docker to be available and configured; therefore, Cmake > can be used to configure the test(s) to be enabled/disabled appropriately. > > Additionally, the tests should be moved to a new test layer as these tests > are not "integration tests" per se... "acceptance test" is a viable name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8460) Configure sni test based on docker availablility
[ https://issues.apache.org/jira/browse/GEODE-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188899#comment-17188899 ] ASF GitHub Bot commented on GEODE-8460: --- mmartell commented on pull request #647: URL: https://github.com/apache/geode-native/pull/647#issuecomment-685222727 > I'm excited about this! It seems like there is a new category of `acceptance-test`. There should be an update to CONTRIBUTING.md to make sure that contributors run tests in the acceptance test directory Good catch moleske! In fact I think geode-native is sorely lacking in documentation on how to use the new test frameworks to write tests. I'm told geode also is lacking in this area. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Configure sni test based on docker availablility > > > Key: GEODE-8460 > URL: https://issues.apache.org/jira/browse/GEODE-8460 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Labels: pull-request-available > > The SNI tests require docker to be available and configured; therefore, Cmake > can be used to configure the test(s) to be enabled/disabled appropriately. > > Additionally, the tests should be moved to a new test layer as these tests > are not "integration tests" per se... "acceptance test" is a viable name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8467) server fails to notify of a ForcedDisconnect and fails to tear down the cache
[
https://issues.apache.org/jira/browse/GEODE-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8467:
Fix Version/s: 1.14.0
> server fails to notify of a ForcedDisconnect and fails to tear down the cache
> -
>
> Key: GEODE-8467
> URL: https://issues.apache.org/jira/browse/GEODE-8467
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.0, 1.14.0
>
>
> A test having auto-reconnect enabled failed while restarting a server and
> hung. The restarting server was building its cache when it was kicked out of
> the cluster due to very high load on the test machine. Membership initiated
> a forced-disconnect
> {noformat}
> [fatal 2020/08/22 00:51:04.508 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> Membership service failure: Member isn't responding to heartbeat requests
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2012)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:688)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1331)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1267)
> {noformat}
>
> and then logged that it was generating a description of the cache
> {noformat}
> [info 2020/08/22 00:51:05.933 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> generating XML to rebuild the cache after reconnect completes {noformat}
>
> but it never logged completion of this step and never forked a thread to tear
> down the cache. Any exception thrown by XML generation would have been
> caught by JGroups code, which logs the problem at a WARNING level. We have
> JGroups logging set to FATAL level so you wouldn't see the issue.
> We need to add exception handling around XML generation and, if detected,
> disable reconnect attempts and have the server shut down.
> The bug isn't easy to hit. I've run the test that failed over 5000 times
> without encountering it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8455) Different behavior in transactions on partitioned regions between creating the region with a parallel gateway sender vs altering the region to add the parallel gateway s
[ https://issues.apache.org/jira/browse/GEODE-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8455. - Fix Version/s: 1.14.0 Resolution: Fixed > Different behavior in transactions on partitioned regions between creating > the region with a parallel gateway sender vs altering the region to add the > parallel gateway sender > -- > > Key: GEODE-8455 > URL: https://issues.apache.org/jira/browse/GEODE-8455 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When creating a partitioned region and then altering it by adding a parallel > gateway sender, I have observed that, when sending transactions to the > partitioned region, an event (GatewaySenderEvent) for each transaction is > sent to every server hosting buckets for the partitioned region and not only > to that/those hosting the bucket where the data in the transaction belongs. > So, for example, in a partitioned region provided by two cache servers where > redundancy is zero, when a transaction is sent, the put is done on the server > hosting the bucket where the data in the transaction is to be stored but an > event for the put is sent to the two members. This provokes in the server not > hosting locally the bucket for the data in the event that the event > (GatewaySenderEvent) is stored in the bucketToTempQueueMap member variable of > the ParallelGatewaySenderQueue. > Those events are eventually removed from that member as events are sent by > the gateway sender to the remote site. Nevertheless, if the remote site > cannot be reached, the events are kept in that member which could provoke a > heap exhaustion problem if there is a sufficient amount of incoming > transactions and the remote site cannot be reached for the required amount of > time. > Events for a transaction should only be sent to the servers hosting the > bucket for the data in the transaction and not to all servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8460) Configure sni test based on docker availablility
[ https://issues.apache.org/jira/browse/GEODE-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188912#comment-17188912 ] ASF GitHub Bot commented on GEODE-8460: --- moleske commented on pull request #647: URL: https://github.com/apache/geode-native/pull/647#issuecomment-685231238 > I think geode-native is sorely lacking in documentation on how to use the new test frameworks For this PR, I think just a one liner mentioning they exist is a good enough. Agree that it could be better in both places This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Configure sni test based on docker availablility > > > Key: GEODE-8460 > URL: https://issues.apache.org/jira/browse/GEODE-8460 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Labels: pull-request-available > > The SNI tests require docker to be available and configured; therefore, Cmake > can be used to configure the test(s) to be enabled/disabled appropriately. > > Additionally, the tests should be moved to a new test layer as these tests > are not "integration tests" per se... "acceptance test" is a viable name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8469) Enforce no-missing-variable-declarations
[
https://issues.apache.org/jira/browse/GEODE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188935#comment-17188935
]
ASF GitHub Bot commented on GEODE-8469:
---
moleske commented on a change in pull request #645:
URL: https://github.com/apache/geode-native/pull/645#discussion_r481562738
##
File path: tests/cpp/security/XmlAuthzCredentialGenerator.hpp
##
@@ -55,7 +55,7 @@ const opCodeList::value_type QArr[] = {OP_QUERY,
OP_REGISTER_CQ};
const stringList::value_type QRArr[] = {"Portfolios", "Positions"};
-const char* PRiUsnm = "%s%d";
+static const char* PRiUsnm = "%s%d";
Review comment:
It did not. `ISO C++11 does not allow conversion from string literal to
'char *const'` is the specific error when trying to use it while on a mac.
Haven't looked more into at the moment
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Enforce no-missing-variable-declarations
>
>
> Key: GEODE-8469
> URL: https://issues.apache.org/jira/browse/GEODE-8469
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Oleske
>Priority: Major
> Labels: pull-request-available
>
> Given I compile the code without exempting no-missing-variable-declarations
> Then it should compile
> Note - was marked as a todo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8475) Resolve a potential dead lock in ParallelGatewaySenderQueue
[
https://issues.apache.org/jira/browse/GEODE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188987#comment-17188987
]
ASF GitHub Bot commented on GEODE-8475:
---
gesterzhou commented on a change in pull request #5492:
URL: https://github.com/apache/geode/pull/5492#discussion_r481718201
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
##
@@ -755,12 +755,16 @@ public boolean put(Object object) throws
InterruptedException, CacheException {
bucketFullPath, brq);
}
if (brq != null) {
+boolean intializingLocked = brq.lockWhenRegionIsInitializing();
Review comment:
added.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Resolve a potential dead lock in ParallelGatewaySenderQueue
>
>
> Key: GEODE-8475
> URL: https://issues.apache.org/jira/browse/GEODE-8475
> Project: Geode
> Issue Type: Improvement
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> When brq is created but encountered a failed GII, enqueue to it could have a
> potential deadlock:
> Thread-1:
> ParallelGatewaySenderQueue.put() will get a
> brq.getInitializationLock().readLock().lock() (lock-A’s read lock). Then
> during the put operation, it will try to call lockWhenRegionIsInitializing()
> to get failedInitialImageLock.readLock().lock (lock-B’s read lock)
> Thread-2:
> PRDS.createBucketRegion() will trigger GII but failed. So it will call
> cleanUpAfterFailedGII(), where it will call lockFailedInitialImageWriteLock
> () to get lock-B’s write lock first. Then call
> BucketRegionQueue.clearEntries().
> It will call getInitializationLock().writeLock().lock() (lock-A’s write lock).
> To fix it, we need to let thread-1 to get failedInitialImageLock.readLock()
> (lock-B) before requesting lock-A.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8475) Resolve a potential dead lock in ParallelGatewaySenderQueue
[
https://issues.apache.org/jira/browse/GEODE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188988#comment-17188988
]
ASF GitHub Bot commented on GEODE-8475:
---
gesterzhou commented on a change in pull request #5492:
URL: https://github.com/apache/geode/pull/5492#discussion_r481718727
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
##
@@ -755,12 +755,16 @@ public boolean put(Object object) throws
InterruptedException, CacheException {
bucketFullPath, brq);
}
if (brq != null) {
+boolean intializingLocked = brq.lockWhenRegionIsInitializing();
brq.getInitializationLock().readLock().lock();
try {
putIntoBucketRegionQueue(brq, key, value);
putDone = true;
} finally {
brq.getInitializationLock().readLock().unlock();
+ if (intializingLocked) {
Review comment:
yes
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Resolve a potential dead lock in ParallelGatewaySenderQueue
>
>
> Key: GEODE-8475
> URL: https://issues.apache.org/jira/browse/GEODE-8475
> Project: Geode
> Issue Type: Improvement
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> When brq is created but encountered a failed GII, enqueue to it could have a
> potential deadlock:
> Thread-1:
> ParallelGatewaySenderQueue.put() will get a
> brq.getInitializationLock().readLock().lock() (lock-A’s read lock). Then
> during the put operation, it will try to call lockWhenRegionIsInitializing()
> to get failedInitialImageLock.readLock().lock (lock-B’s read lock)
> Thread-2:
> PRDS.createBucketRegion() will trigger GII but failed. So it will call
> cleanUpAfterFailedGII(), where it will call lockFailedInitialImageWriteLock
> () to get lock-B’s write lock first. Then call
> BucketRegionQueue.clearEntries().
> It will call getInitializationLock().writeLock().lock() (lock-A’s write lock).
> To fix it, we need to let thread-1 to get failedInitialImageLock.readLock()
> (lock-B) before requesting lock-A.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
