[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=17189320#comment-17189320
]
ASF GitHub Bot commented on GEODE-8460:
---
pdxcodemonkey commented on a change in pull request #647:
URL: https://github.com/apache/geode-native/pull/647#discussion_r482166019
##
File path: cppcache/integration/test/sni-test-config/docker-compose.yml
##
@@ -1,43 +0,0 @@
-#
Review comment:
Let's get our act together with respect to all these support files for
the SNI tests before we merge this. There's now a geode.properties in _both_
the CLI and the C++ `acceptance-test` directories, are they the same? If so,
they should be in a common area. You've removed the `sni-test-config`
directory from the integration tests, and there's an `sni-test-config` dir at
the top level of the project, are the tests pulling everything from this
directory? There is, at least, a file `truststore_sni.pem` in
`/sni-test-config/geode-config` and there's also one, from earlier refactoring,
in `/ssl_keys/client_keys` - there can be only one! Also, we're installing SSL
certs via INSTALL in CMakeLists.txt. Please don't do this, we spent a lot of
effort removing duplicate SSL certs/keys - tests should always pick these up
from the source directory via defined constants in TestConfig.h or Config.cs.
##
File path: cppcache/integration/test/CMakeLists.txt
##
@@ -97,7 +96,7 @@ configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/func_cacheserver2_pool.xml
${CMAKE_CURRENT_BINARY_DIR}/func_cacheserver2_pool.xml COPYONLY)
- file(COPY ${CMAKE_CURRENT_SOURCE_DIR}/sni-test-config DESTINATION
${CMAKE_CURRENT_BINARY_DIR})
+#file(COPY ${CMAKE_CURRENT_SOURCE_DIR}/sni-test-config DESTINATION
${CMAKE_CURRENT_BINARY_DIR})
Review comment:
Please remove commented lines
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] [Created] (GEODE-8479) Remove call to deleted function GemFireVersion.getBuildDate
Blake Bender created GEODE-8479: --- Summary: Remove call to deleted function GemFireVersion.getBuildDate Key: GEODE-8479 URL: https://issues.apache.org/jira/browse/GEODE-8479 Project: Geode Issue Type: Improvement Components: native client Reporter: Blake Bender The changes for GEODE-8458 removed this method from the class, and the native client is trivially calling it in a trace statement. Until this is removed from the native codebase, we won't be able to build against the latest Geode source. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8479) Remove call to deleted function GemFireVersion.getBuildDate
[ https://issues.apache.org/jira/browse/GEODE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189346#comment-17189346 ] ASF subversion and git services commented on GEODE-8479: Commit 3046ae647cf2bb152ddec40264a7f681fa8dde5d in geode-native's branch refs/heads/develop from M. Oleske [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=3046ae6 ] GEODE-8479: Remove GemFireVersion.getBuildDate() (#644) This [commit](https://github.com/apache/geode/commit/d9d13100ae11e2eba8a6428fad29007388680b43#diff-a377b15d2036a2fc9072c1915c7f0ed4L83) removed getBuildDate() in the java code, causing geode native develop to fail to compile with geode develop > Remove call to deleted function GemFireVersion.getBuildDate > --- > > Key: GEODE-8479 > URL: https://issues.apache.org/jira/browse/GEODE-8479 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > The changes for GEODE-8458 removed this method from the class, and the native > client is trivially calling it in a trace statement. Until this is removed > from the native codebase, we won't be able to build against the latest Geode > source. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8479) Remove call to deleted function GemFireVersion.getBuildDate
[ https://issues.apache.org/jira/browse/GEODE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-8479. --- > Remove call to deleted function GemFireVersion.getBuildDate > --- > > Key: GEODE-8479 > URL: https://issues.apache.org/jira/browse/GEODE-8479 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > The changes for GEODE-8458 removed this method from the class, and the native > client is trivially calling it in a trace statement. Until this is removed > from the native codebase, we won't be able to build against the latest Geode > source. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8479) Remove call to deleted function GemFireVersion.getBuildDate
[ https://issues.apache.org/jira/browse/GEODE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-8479. - Resolution: Fixed > Remove call to deleted function GemFireVersion.getBuildDate > --- > > Key: GEODE-8479 > URL: https://issues.apache.org/jira/browse/GEODE-8479 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > The changes for GEODE-8458 removed this method from the class, and the native > client is trivially calling it in a trace statement. Until this is removed > from the native codebase, we won't be able to build against the latest Geode > source. -- 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=17189365#comment-17189365
]
ASF GitHub Bot commented on GEODE-8404:
---
demery-pivotal merged pull request #5493:
URL: https://github.com/apache/geode/pull/5493
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}} 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] [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=17189366#comment-17189366
]
ASF subversion and git services commented on GEODE-8404:
Commit 547542ec9f05893e9e484d5be46efe83cdfc33e0 in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=547542e ]
GEODE-8404: Simplify AvailablePortHelper (#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.
> 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] [Updated] (GEODE-8480) Add tx manager check in geode-native transaction example
[ https://issues.apache.org/jira/browse/GEODE-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-8480: Priority: Minor (was: Major) > Add tx manager check in geode-native transaction example > > > Key: GEODE-8480 > URL: https://issues.apache.org/jira/browse/GEODE-8480 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Alberto Bustamante Reyes >Priority: Minor > > Transactions documentation & example in the geode C++ client is not checking > if the transaction manager exists before calling to rollback, as it is done > in the transactions documentation and example in geode. > I have seen that depending on the exception, the rollback can generate an > error so I think its something that should be added to the example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8480) Add tx manager check in geode-native transaction example
[ https://issues.apache.org/jira/browse/GEODE-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-8480: --- Assignee: Alberto Bustamante Reyes > Add tx manager check in geode-native transaction example > > > Key: GEODE-8480 > URL: https://issues.apache.org/jira/browse/GEODE-8480 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > > Transactions documentation & example in the geode C++ client is not checking > if the transaction manager exists before calling to rollback, as it is done > in the transactions documentation and example in geode. > I have seen that depending on the exception, the rollback can generate an > error so I think its something that should be added to the example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8480) Add tx manager check in geode-native transaction example
Alberto Bustamante Reyes created GEODE-8480: --- Summary: Add tx manager check in geode-native transaction example Key: GEODE-8480 URL: https://issues.apache.org/jira/browse/GEODE-8480 Project: Geode Issue Type: Improvement Components: docs, native client Reporter: Alberto Bustamante Reyes Transactions documentation & example in the geode C++ client is not checking if the transaction manager exists before calling to rollback, as it is done in the transactions documentation and example in geode. I have seen that depending on the exception, the rollback can generate an error so I think its something that should be added to the example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8480) Add tx manager check in geode-native transaction example
[ https://issues.apache.org/jira/browse/GEODE-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8480: -- Labels: pull-request-available (was: ) > Add tx manager check in geode-native transaction example > > > Key: GEODE-8480 > URL: https://issues.apache.org/jira/browse/GEODE-8480 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > > Transactions documentation & example in the geode C++ client is not checking > if the transaction manager exists before calling to rollback, as it is done > in the transactions documentation and example in geode. > I have seen that depending on the exception, the rollback can generate an > error so I think its something that should be added to the example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8480) Add tx manager check in geode-native transaction example
[ https://issues.apache.org/jira/browse/GEODE-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189565#comment-17189565 ] ASF GitHub Bot commented on GEODE-8480: --- alb3rtobr opened a new pull request #648: URL: https://github.com/apache/geode-native/pull/648 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 > Add tx manager check in geode-native transaction example > > > Key: GEODE-8480 > URL: https://issues.apache.org/jira/browse/GEODE-8480 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > > Transactions documentation & example in the geode C++ client is not checking > if the transaction manager exists before calling to rollback, as it is done > in the transactions documentation and example in geode. > I have seen that depending on the exception, the rollback can generate an > error so I think its something that should be added to the example. -- 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=17189577#comment-17189577 ] ASF GitHub Bot commented on GEODE-8475: --- gesterzhou merged pull request #5492: URL: https://github.com/apache/geode/pull/5492 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=17189578#comment-17189578 ] ASF subversion and git services commented on GEODE-8475: Commit b62e033af490d6f1e8f40621ff084b099f5b52e8 in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b62e033 ] GEODE-8475: Resolve a potential dead lock in ParallelGatewaySenderQueue (#5492) Co-authored-by: Darrel Schneider > 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-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=17189614#comment-17189614
]
ASF GitHub Bot commented on GEODE-8478:
---
DonalEvans commented on a change in pull request #5494:
URL: https://github.com/apache/geode/pull/5494#discussion_r482268033
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/AbstractGatewaySenderEventProcessor.java
##
@@ -1037,24 +1039,32 @@ public void handleSuccessBatchAck(int batchId) {
}
eventQueueRemove(events.size());
- final GatewaySenderStats statistics = this.sender.getStatistics();
+ logThresholdExceededAlerts(events);
+}
+ }
- // Log an alert for each event if necessary
- if (this.sender.getAlertThreshold() > 0) {
-Iterator it = events.iterator();
-long currentTime = System.currentTimeMillis();
-while (it.hasNext()) {
+ protected void logThresholdExceededAlerts(List
events) {
+// Log an alert for each event if necessary
+if (getSender().getAlertThreshold() > 0) {
+ Iterator it = events.iterator();
+ long currentTime = System.currentTimeMillis();
+ while (it.hasNext()) {
+try {
Object o = it.next();
if (o != null && o instanceof GatewaySenderEventImpl) {
Review comment:
This null check is redundant, since it's implicitly included in the
`instanceof` check.
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
> 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-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=17189622#comment-17189622 ] ASF GitHub Bot commented on GEODE-8460: --- echobravopapa commented on a change in pull request #647: URL: https://github.com/apache/geode-native/pull/647#discussion_r482281695 ## File path: cppcache/integration/test/sni-test-config/docker-compose.yml ## @@ -1,43 +0,0 @@ -# Review comment: second that. 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-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=17189664#comment-17189664
]
ASF GitHub Bot commented on GEODE-8478:
---
boglesby commented on a change in pull request #5494:
URL: https://github.com/apache/geode/pull/5494#discussion_r482347901
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/AbstractGatewaySenderEventProcessor.java
##
@@ -1037,24 +1039,32 @@ public void handleSuccessBatchAck(int batchId) {
}
eventQueueRemove(events.size());
- final GatewaySenderStats statistics = this.sender.getStatistics();
+ logThresholdExceededAlerts(events);
+}
+ }
- // Log an alert for each event if necessary
- if (this.sender.getAlertThreshold() > 0) {
-Iterator it = events.iterator();
-long currentTime = System.currentTimeMillis();
-while (it.hasNext()) {
+ protected void logThresholdExceededAlerts(List
events) {
+// Log an alert for each event if necessary
+if (getSender().getAlertThreshold() > 0) {
+ Iterator it = events.iterator();
+ long currentTime = System.currentTimeMillis();
+ while (it.hasNext()) {
+try {
Object o = it.next();
if (o != null && o instanceof GatewaySenderEventImpl) {
Review comment:
Thanks for reviewing this change. I tend to not change existing code if
I can help it, but since I pulled this method out, I'll refactor it. it could
use other work too.
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
> 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=17189666#comment-17189666
]
ASF subversion and git services commented on GEODE-8478:
Commit 2350764eafa204c101b45723371917b5a3395bda in geode's branch
refs/heads/feature/GEODE-8478 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2350764 ]
GEODE-8478: Refactored the logThresholdExceededAlerts method
> 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] [Resolved] (GEODE-8475) Resolve a potential dead lock in ParallelGatewaySenderQueue
[ https://issues.apache.org/jira/browse/GEODE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-8475. -- Fix Version/s: 1.14.0 Resolution: Fixed > 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 > Fix For: 1.14.0 > > > 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=17189750#comment-17189750 ] ASF subversion and git services commented on GEODE-8475: Commit 52b932bb6847dcc89c357c7e5ec960566ad965c7 in geode's branch refs/heads/support/1.13 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=52b932b ] GEODE-8475: Resolve a potential dead lock in ParallelGatewaySenderQueue (#5492) Co-authored-by: Darrel Schneider (cherry picked from commit b62e033af490d6f1e8f40621ff084b099f5b52e8) > 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 > Fix For: 1.14.0 > > > 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-8432) use regionPath directly instead of getRegion when put event into parallelGatewaySenderQueue
[ https://issues.apache.org/jira/browse/GEODE-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189755#comment-17189755 ] ASF GitHub Bot commented on GEODE-8432: --- gesterzhou closed pull request #5489: URL: https://github.com/apache/geode/pull/5489 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 > use regionPath directly instead of getRegion when put event into > parallelGatewaySenderQueue > --- > > Key: GEODE-8432 > URL: https://issues.apache.org/jira/browse/GEODE-8432 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.13.0, 1.14.0 > > > ParallelGatewaySenderQueue tried to put but find the value's reference to > region is null. > When the put happens, the data region might be in middle of GII. Need to > error handle this case. > It looks like the member received the reply from SyncWith message for the > queue. > But when the member tried to put the event into its own queue, and find the > local data region is not ready. (because it's in middle of GII or recovery) > The stack trace is: > at > org.apache.geode.internal.cache.CacheFactoryStatics.getAnyInstance(CacheFactoryStatics.java:85) > at > org.apache.geode.cache.CacheFactory.getAnyInstance(CacheFactory.java:396) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getRegion(GatewaySenderEventImpl.java:1217) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.put(ParallelGatewaySenderQueue.java:696) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.enqueueEvent(ParallelGatewaySenderEventProcessor.java:138) > at > org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.enqueueEvent(ConcurrentParallelGatewaySenderEventProcessor.java:354) > at > org.apache.geode.internal.cache.wan.AbstractGatewaySender.putSynchronizationEvent(AbstractGatewaySender.java:1507) > at > org.apache.geode.internal.cache.wan.GatewaySenderQueueEntrySynchronizationOperation$GatewaySenderQueueEntrySynchronizationReplyProcessor.putSynchronizationEvents(GatewaySenderQueueEntrySynchronizationOperation.java:162) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8432) use regionPath directly instead of getRegion when put event into parallelGatewaySenderQueue
[ https://issues.apache.org/jira/browse/GEODE-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189756#comment-17189756 ] ASF GitHub Bot commented on GEODE-8432: --- gesterzhou commented on pull request #5489: URL: https://github.com/apache/geode/pull/5489#issuecomment-686086161 This fix did not consider the region destroy will cause it return null. Close it. 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 > use regionPath directly instead of getRegion when put event into > parallelGatewaySenderQueue > --- > > Key: GEODE-8432 > URL: https://issues.apache.org/jira/browse/GEODE-8432 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.13.0, 1.14.0 > > > ParallelGatewaySenderQueue tried to put but find the value's reference to > region is null. > When the put happens, the data region might be in middle of GII. Need to > error handle this case. > It looks like the member received the reply from SyncWith message for the > queue. > But when the member tried to put the event into its own queue, and find the > local data region is not ready. (because it's in middle of GII or recovery) > The stack trace is: > at > org.apache.geode.internal.cache.CacheFactoryStatics.getAnyInstance(CacheFactoryStatics.java:85) > at > org.apache.geode.cache.CacheFactory.getAnyInstance(CacheFactory.java:396) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getRegion(GatewaySenderEventImpl.java:1217) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.put(ParallelGatewaySenderQueue.java:696) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.enqueueEvent(ParallelGatewaySenderEventProcessor.java:138) > at > org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.enqueueEvent(ConcurrentParallelGatewaySenderEventProcessor.java:354) > at > org.apache.geode.internal.cache.wan.AbstractGatewaySender.putSynchronizationEvent(AbstractGatewaySender.java:1507) > at > org.apache.geode.internal.cache.wan.GatewaySenderQueueEntrySynchronizationOperation$GatewaySenderQueueEntrySynchronizationReplyProcessor.putSynchronizationEvents(GatewaySenderQueueEntrySynchronizationOperation.java:162) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8475) Resolve a potential dead lock in ParallelGatewaySenderQueue
[ https://issues.apache.org/jira/browse/GEODE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-8475: - Fix Version/s: 1.13.0 > 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 > Fix For: 1.13.0, 1.14.0 > > > 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-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=17189802#comment-17189802 ] ASF GitHub Bot commented on GEODE-8460: --- mmartell commented on a change in pull request #647: URL: https://github.com/apache/geode-native/pull/647#discussion_r482669955 ## File path: cppcache/integration/test/sni-test-config/docker-compose.yml ## @@ -1,43 +0,0 @@ -# Review comment: Good catch on the unnecessary geode.properties in the clicache/acceptance-test folder. Has now been removed. Don't see one in the cppcache/acceptance-test folder. The cppcache/integration/test/sni-test-config was removed, as all sni tests are pulling from sni-test-config that resides in the root folder. Good catch on the duplicate truststore_sni.pem. Makes good sense to not duplicate files, particularly cert files. SNI tests have been modified to pull this client side truststore from the ssl_keys/client_keys folder. 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=17189820#comment-17189820 ] ASF GitHub Bot commented on GEODE-8460: --- mmartell commented on a change in pull request #647: URL: https://github.com/apache/geode-native/pull/647#discussion_r482669955 ## File path: cppcache/integration/test/sni-test-config/docker-compose.yml ## @@ -1,43 +0,0 @@ -# Review comment: Good catch on the unnecessary geode.properties in the clicache/acceptance-test folder. Has now been removed. Don't see one in the cppcache/acceptance-test folder. The cppcache/integration/test/sni-test-config was removed, as all sni tests are pulling from sni-test-config that resides in the root folder. Good catch on the duplicate truststore_sni.pem. It has now been removed. SNI tests had already been modified to pull this client side truststore from the ssl_keys/client_keys folder. 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)
