[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242150#comment-17242150
]
ASF GitHub Bot commented on GEODE-8742:
---
mkevo closed pull request #5777:
URL: https://github.com/apache/geode/pull/5777
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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242148#comment-17242148
]
ASF GitHub Bot commented on GEODE-8742:
---
mkevo commented on a change in pull request #5777:
URL: https://github.com/apache/geode/pull/5777#discussion_r533977672
##
File path:
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderImpl.java
##
@@ -117,15 +117,8 @@ private void start(boolean cleanQueues) {
}
protected AbstractGatewaySenderEventProcessor createEventProcessor(boolean
cleanQueues) {
-AbstractGatewaySenderEventProcessor eventProcessor;
-if (getDispatcherThreads() > 1) {
- eventProcessor = new RemoteConcurrentSerialGatewaySenderEventProcessor(
- SerialGatewaySenderImpl.this, getThreadMonitorObj(), cleanQueues);
-} else {
- eventProcessor = new
RemoteSerialGatewaySenderEventProcessor(SerialGatewaySenderImpl.this,
- getId(), getThreadMonitorObj(), cleanQueues);
-}
-return eventProcessor;
+return new RemoteConcurrentSerialGatewaySenderEventProcessor(
+SerialGatewaySenderImpl.this, getThreadMonitorObj(), cleanQueues);
Review comment:
Hi @DonalEvans ,
I agree with you, I will close this PR and open a new one with new fix.
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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242216#comment-17242216
]
ASF GitHub Bot commented on GEODE-8742:
---
mkevo opened a new pull request #5803:
URL: https://github.com/apache/geode/pull/5803
…to 1
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:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [x] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [x] Is your initial contribution a single, squashed commit?
- [x] 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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242219#comment-17242219
]
ASF GitHub Bot commented on GEODE-8742:
---
mkevo commented on pull request #5777:
URL: https://github.com/apache/geode/pull/5777#issuecomment-737125881
The new PR is opened [#5803](https://github.com/apache/geode/pull/5803).
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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8202) New option for serial gw sender threads start when receivers share ip and port
[
https://issues.apache.org/jira/browse/GEODE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242255#comment-17242255
]
ASF GitHub Bot commented on GEODE-8202:
---
alb3rtobr commented on a change in pull request #5600:
URL: https://github.com/apache/geode/pull/5600#discussion_r534079046
##
File path:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcherJUnitTest.java
##
@@ -77,4 +132,160 @@ public void
getConnectionShouldCreateNewConnectionWhenServerIsNull() {
verify(dispatcher, times(1)).initializeConnection();
verify(dispatcher, times(2)).getConnectionLifeCycleLock();
}
+
+ @Test
+ public void
enforceThreadsConnectSameReceiver_initializeParallelSenderConnection_retriesAreNotUsed()
{
Review comment:
I read the article when you posted it the first time (interesting
reading, thanks!) and tried to follow the
`UnitOfWork_StateUnderTest_ExpectedBehavior` schema they propose (which btw I
found it very similar to the `given-when-then` naming approach). It seems I did
not understand the article in the same way as you, sorry. I used
`enforceThreadsConnectSameReceiver` as `UnitOfWork` because this is what this
PR is introducing.
The names you have proposed look fine for me, they really look like
requirements when you read them.
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
> New option for serial gw sender threads start when receivers share ip and port
> --
>
> Key: GEODE-8202
> URL: https://issues.apache.org/jira/browse/GEODE-8202
> Project: Geode
> Issue Type: Improvement
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> RFC:
> [https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start|https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8202) New option for serial gw sender threads start when receivers share ip and port
[
https://issues.apache.org/jira/browse/GEODE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242270#comment-17242270
]
ASF GitHub Bot commented on GEODE-8202:
---
alb3rtobr commented on a change in pull request #5600:
URL: https://github.com/apache/geode/pull/5600#discussion_r534093886
##
File path:
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
##
@@ -348,11 +349,56 @@ public void destroyConnection() {
}
}
+ Connection retryInitializeConnection(Connection con) {
+final boolean isDebugEnabled = logger.isDebugEnabled();
+ServerLocation server = this.sender.getServerLocation();
+String connectedServerId = con.getEndpoint().getMemberId().getUniqueId();
+String expectedServerId = this.processor.getExpectedReceiverUniqueId();
+boolean connectedToExpectedReceiver =
connectedServerId.equals(expectedServerId);
+if (expectedServerId.equals("")) {
+ if (isDebugEnabled) {
+logger.debug("First dispatcher connected to endpoint " +
connectedServerId);
+ }
+ this.processor.setExpectedReceiverUniqueId(connectedServerId);
+ connectedToExpectedReceiver = true;
+}
+int attempt = 0;
+final int maxAttempts = 5;
Review comment:
With the approach I was suggesting, we will have `x * y ` attempts to
connect to the desired receiver, being `x=5` (or any other number) and
`y=`.
I think this is a high enough number to guarantee we reach the receiver we
want. As you said, we are not setting the probability of not reaching the
proper server to zero, but I think we are reducing it to a reasonable value.
I will add a commit with the change.
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
> New option for serial gw sender threads start when receivers share ip and port
> --
>
> Key: GEODE-8202
> URL: https://issues.apache.org/jira/browse/GEODE-8202
> Project: Geode
> Issue Type: Improvement
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> RFC:
> [https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start|https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8756) CacheableString objectSize is not correct
Mario Salazar de Torres created GEODE-8756: -- Summary: CacheableString objectSize is not correct Key: GEODE-8756 URL: https://issues.apache.org/jira/browse/GEODE-8756 Project: Geode Issue Type: Sub-task Components: native client Affects Versions: 1.13.1, 1.13.0, 1.12.0, 1.11.0 Reporter: Mario Salazar de Torres CacheableString objectSize function is returning an incorrect value. This class is based upon STL's string implementation, and most of the compilers implementations apply what's called SSO. What SSO basically does is if the string occupies less than a certain amount, no extra memory would be allocated in the heap, and the character-sequence would be stored in the object itself. This is typically achieved by using union semantics. Right now if SSO applies, objectSize calculates the size of std::string as sizeof(std::string) + m_str.capacity(), which is more than it actually occupies. On the other hand starting C++11 STL's strings needs to allocate an extra character to keep the null-terminator in the same buffer as the actual string. This is specified in section § 21.4.7.1 within the C++11 standard. Because of this objectSize should take the null-terminator into account, which was not the case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8750) Size tracking for LRUEntriesMap is not accurate
[ https://issues.apache.org/jira/browse/GEODE-8750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-8750: --- Affects Version/s: 1.13.1 > Size tracking for LRUEntriesMap is not accurate > --- > > Key: GEODE-8750 > URL: https://issues.apache.org/jira/browse/GEODE-8750 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.12.0, 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Priority: Major > > LRUEntriesMap uses only key and value object size to keep track of the heap > memory consumed by the entries. > Thing is there are some more pieces of memory involved in storing this > entries and they are not being taken into account. Those are: > * Hash table internals memory (buckets, nodes...). > * Smart pointer internals (control block...). > * Any other memory used to store information about the LRUMap. > The purpose of this issue is to set the line on when it is reasonable to stop > measuring the heap memory consumed, and after that put in place a proper > implementation to track used heap memory within what's feasible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8756) CacheableString objectSize is not correct
[ https://issues.apache.org/jira/browse/GEODE-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-8756: -- Assignee: Mario Salazar de Torres > CacheableString objectSize is not correct > - > > Key: GEODE-8756 > URL: https://issues.apache.org/jira/browse/GEODE-8756 > Project: Geode > Issue Type: Sub-task > Components: native client >Affects Versions: 1.11.0, 1.12.0, 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > CacheableString objectSize function is returning an incorrect value. > This class is based upon STL's string implementation, and most of the > compilers implementations apply what's called SSO. > What SSO basically does is if the string occupies less than a certain amount, > no extra memory would be allocated in the heap, and the character-sequence > would be stored in the object itself. This is typically achieved by using > union semantics. > Right now if SSO applies, objectSize calculates the size of std::string as > sizeof(std::string) + m_str.capacity(), which is more than it actually > occupies. > On the other hand starting C++11 STL's strings needs to allocate an extra > character > to keep the null-terminator in the same buffer as the actual string. This is > specified in section § 21.4.7.1 within the C++11 standard. > Because of this objectSize should take the null-terminator into account, > which was not the case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8757) Allow compilation of geode examples with Java 11 on Travis CI
Ashish Choudhary created GEODE-8757: --- Summary: Allow compilation of geode examples with Java 11 on Travis CI Key: GEODE-8757 URL: https://issues.apache.org/jira/browse/GEODE-8757 Project: Geode Issue Type: New Feature Components: examples Reporter: Ashish Choudhary Currently Travis CI builds are failing if Java 11 API is used in geode examples. We should change default version from 8 to 11 for Travis CI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8757) Allow build of geode examples with Java 11 on Travis CI
[ https://issues.apache.org/jira/browse/GEODE-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Choudhary updated GEODE-8757: Summary: Allow build of geode examples with Java 11 on Travis CI (was: Allow compilation of geode examples with Java 11 on Travis CI) > Allow build of geode examples with Java 11 on Travis CI > --- > > Key: GEODE-8757 > URL: https://issues.apache.org/jira/browse/GEODE-8757 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Priority: Major > > Currently Travis CI builds are failing if Java 11 API is used in geode > examples. We should change default version from 8 to 11 for Travis CI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8756) CacheableString objectSize is not correct
[ https://issues.apache.org/jira/browse/GEODE-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8756: -- Labels: pull-request-available (was: ) > CacheableString objectSize is not correct > - > > Key: GEODE-8756 > URL: https://issues.apache.org/jira/browse/GEODE-8756 > Project: Geode > Issue Type: Sub-task > Components: native client >Affects Versions: 1.11.0, 1.12.0, 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > CacheableString objectSize function is returning an incorrect value. > This class is based upon STL's string implementation, and most of the > compilers implementations apply what's called SSO. > What SSO basically does is if the string occupies less than a certain amount, > no extra memory would be allocated in the heap, and the character-sequence > would be stored in the object itself. This is typically achieved by using > union semantics. > Right now if SSO applies, objectSize calculates the size of std::string as > sizeof(std::string) + m_str.capacity(), which is more than it actually > occupies. > On the other hand starting C++11 STL's strings needs to allocate an extra > character > to keep the null-terminator in the same buffer as the actual string. This is > specified in section § 21.4.7.1 within the C++11 standard. > Because of this objectSize should take the null-terminator into account, > which was not the case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8756) CacheableString objectSize is not correct
[ https://issues.apache.org/jira/browse/GEODE-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242404#comment-17242404 ] ASF GitHub Bot commented on GEODE-8756: --- gaussianrecurrence opened a new pull request #703: URL: https://github.com/apache/geode-native/pull/703 - objectSize was not taking into account null-terminator character, which as of C++11, as stated in § 21.4.7.1, should be included at the end of the same string character sequence. - Also, in those cases in which SSO applied, the returned size was higher than the actual one. - A parametrized UT was added to check objectSize is returning the right size. Note that no fixed sizes are part of such test, given that each std::string implementation could have a different SSO size. 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 > CacheableString objectSize is not correct > - > > Key: GEODE-8756 > URL: https://issues.apache.org/jira/browse/GEODE-8756 > Project: Geode > Issue Type: Sub-task > Components: native client >Affects Versions: 1.11.0, 1.12.0, 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > CacheableString objectSize function is returning an incorrect value. > This class is based upon STL's string implementation, and most of the > compilers implementations apply what's called SSO. > What SSO basically does is if the string occupies less than a certain amount, > no extra memory would be allocated in the heap, and the character-sequence > would be stored in the object itself. This is typically achieved by using > union semantics. > Right now if SSO applies, objectSize calculates the size of std::string as > sizeof(std::string) + m_str.capacity(), which is more than it actually > occupies. > On the other hand starting C++11 STL's strings needs to allocate an extra > character > to keep the null-terminator in the same buffer as the actual string. This is > specified in section § 21.4.7.1 within the C++11 standard. > Because of this objectSize should take the null-terminator into account, > which was not the case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8758) Downgrade testcontainers from 1.15.0 to 1.14.3
[ https://issues.apache.org/jira/browse/GEODE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-8758: - Assignee: Jens Deppe > Downgrade testcontainers from 1.15.0 to 1.14.3 > -- > > Key: GEODE-8758 > URL: https://issues.apache.org/jira/browse/GEODE-8758 > Project: Geode > Issue Type: Test > Components: build, redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > There appears to be a problem with the latest version, causing acceptance > tests to hang. > > Possibly this: > https://github.com/testcontainers/testcontainers-java/issues/3531 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8758) Downgrade testcontainers from 1.15.0 to 1.14.3
Jens Deppe created GEODE-8758: - Summary: Downgrade testcontainers from 1.15.0 to 1.14.3 Key: GEODE-8758 URL: https://issues.apache.org/jira/browse/GEODE-8758 Project: Geode Issue Type: Test Components: build, redis Reporter: Jens Deppe There appears to be a problem with the latest version, causing acceptance tests to hang. Possibly this: https://github.com/testcontainers/testcontainers-java/issues/3531 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8758) Downgrade testcontainers from 1.15.0 to 1.14.3
[ https://issues.apache.org/jira/browse/GEODE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8758: -- Labels: pull-request-available (was: ) > Downgrade testcontainers from 1.15.0 to 1.14.3 > -- > > Key: GEODE-8758 > URL: https://issues.apache.org/jira/browse/GEODE-8758 > Project: Geode > Issue Type: Test > Components: build, redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > There appears to be a problem with the latest version, causing acceptance > tests to hang. > > Possibly this: > https://github.com/testcontainers/testcontainers-java/issues/3531 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8758) Downgrade testcontainers from 1.15.0 to 1.14.3
[ https://issues.apache.org/jira/browse/GEODE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242442#comment-17242442 ] ASF GitHub Bot commented on GEODE-8758: --- jdeppe-pivotal opened a new pull request #5804: URL: https://github.com/apache/geode/pull/5804 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 > Downgrade testcontainers from 1.15.0 to 1.14.3 > -- > > Key: GEODE-8758 > URL: https://issues.apache.org/jira/browse/GEODE-8758 > Project: Geode > Issue Type: Test > Components: build, redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > There appears to be a problem with the latest version, causing acceptance > tests to hang. > > Possibly this: > https://github.com/testcontainers/testcontainers-java/issues/3531 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8759) Update Redis documentation to reflect current supported/unsupported status
Raymond Ingles created GEODE-8759: - Summary: Update Redis documentation to reflect current supported/unsupported status Key: GEODE-8759 URL: https://issues.apache.org/jira/browse/GEODE-8759 Project: Geode Issue Type: Bug Components: redis Affects Versions: 1.14.0 Reporter: Raymond Ingles A handful of new commands are now in the 'unsupported' category but the documentation does not reflect that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8759) Update Redis documentation to reflect current supported/unsupported status
[ https://issues.apache.org/jira/browse/GEODE-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8759: -- Labels: pull-request-available (was: ) > Update Redis documentation to reflect current supported/unsupported status > -- > > Key: GEODE-8759 > URL: https://issues.apache.org/jira/browse/GEODE-8759 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Priority: Major > Labels: pull-request-available > > A handful of new commands are now in the 'unsupported' category but the > documentation does not reflect that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8759) Update Redis documentation to reflect current supported/unsupported status
[ https://issues.apache.org/jira/browse/GEODE-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242482#comment-17242482 ] ASF GitHub Bot commented on GEODE-8759: --- ringles opened a new pull request #5805: URL: https://github.com/apache/geode/pull/5805 … command state - [X ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ X] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ X] Is your initial contribution a single, squashed commit? - [ X] Does `gradlew build` run cleanly? Make sure INFO and HSTRLEN commands are listed in the "Unsupported" section of the documentation and not the "Unimplemented" section. A few minor alphabetization tweaks. 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 > Update Redis documentation to reflect current supported/unsupported status > -- > > Key: GEODE-8759 > URL: https://issues.apache.org/jira/browse/GEODE-8759 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Priority: Major > > A handful of new commands are now in the 'unsupported' category but the > documentation does not reflect that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7846) Clear in Partitioned Region should have its own stats
[ https://issues.apache.org/jira/browse/GEODE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross resolved GEODE-7846. Resolution: Fixed > Clear in Partitioned Region should have its own stats > - > > Key: GEODE-7846 > URL: https://issues.apache.org/jira/browse/GEODE-7846 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI, pull-request-available > > Clear operation in PR should have its own stats: > 1) clear operation executed. > 2) clear operation failed > 3) clear messages sends to buckets -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242536#comment-17242536
]
ASF GitHub Bot commented on GEODE-8755:
---
yozaner1324 commented on a change in pull request #5800:
URL: https://github.com/apache/geode/pull/5800#discussion_r534338470
##
File path:
geode-assembly/src/integrationTest/java/org/apache/geode/BundledJarsJUnitTest.java
##
@@ -67,7 +67,7 @@ public void verifyBundledJarsHaveNotChanged() throws
IOException {
sortedJars.entrySet().stream().map(entry ->
removeVersion(entry.getKey()));
Set bundledJarNames = new
TreeSet<>(lines.collect(Collectors.toSet()));
-Files.write(Paths.get("bundled_jars.txt"), bundledJarNames);
+Files.write(Paths.get("..", "bundled_jars.txt"), bundledJarNames);
Review comment:
This change looks good, however, BundledJarsJUnitTest is not the only
test that has this problem; AssemblyContentsIntegrationTest and
GeodeDependencyJarIntegrationTest also need essentially the same change.
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
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242539#comment-17242539
]
ASF GitHub Bot commented on GEODE-8755:
---
demery-pivotal commented on a change in pull request #5800:
URL: https://github.com/apache/geode/pull/5800#discussion_r534343409
##
File path:
geode-assembly/src/integrationTest/java/org/apache/geode/BundledJarsJUnitTest.java
##
@@ -67,7 +67,7 @@ public void verifyBundledJarsHaveNotChanged() throws
IOException {
sortedJars.entrySet().stream().map(entry ->
removeVersion(entry.getKey()));
Set bundledJarNames = new
TreeSet<>(lines.collect(Collectors.toSet()));
-Files.write(Paths.get("bundled_jars.txt"), bundledJarNames);
+Files.write(Paths.get("..", "bundled_jars.txt"), bundledJarNames);
Review comment:
Can you think of way to identify the tests that have this problem?
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
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242544#comment-17242544
]
ASF GitHub Bot commented on GEODE-8742:
---
DonalEvans commented on a change in pull request #5803:
URL: https://github.com/apache/geode/pull/5803#discussion_r534344699
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/wancommand/ListGatewaysCommandDUnitTest.java
##
@@ -450,6 +450,30 @@ public void
testListGatewaysReceiversOnlyFalseAndSendersOnlyFalseReturnsSendersA
.hasRowSize(expectedGwReceiverSectionSize).hasColumns().contains("Port",
"Member");
}
+ @Test
+ public void testListGatewaysWithOneDispatcherThread() {
+String command =
+"create gateway-sender --id=ln_Serial --remote-distributed-system-id=2
--dispatcher-threads=1";
Review comment:
Instead of hard-coding the gfsh command, would it be possible to use
`CommandStringBuilder` with the static strings found in `CliStrings` 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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242552#comment-17242552
]
Geode Integration commented on GEODE-8760:
--
Seen in [Benchmark_base
#486|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/486].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
Bill Burcham created GEODE-8760:
---
Summary: P2pPartitionedPutBenchmark fails with UnmarshalException
Key: GEODE-8760
URL: https://issues.apache.org/jira/browse/GEODE-8760
Project: Geode
Issue Type: Bug
Components: benchmarks
Affects Versions: 1.14.0
Reporter: Bill Burcham
{code:java}
> Task :geode-benchmarks:benchmark
org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
java.util.concurrent.CompletionException: java.lang.RuntimeException:
java.rmi.UnmarshalException: Error unmarshaling return header; nested exception
is:
java.io.EOFException
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
at
java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by:
java.lang.RuntimeException: java.rmi.UnmarshalException: Error
unmarshaling return header; nested exception is:
java.io.EOFException
at
org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
at
java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
... 3 more
Caused by:
java.rmi.UnmarshalException: Error unmarshaling return header;
nested exception is:
java.io.EOFException
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
at com.sun.proxy.$Proxy13.execute(Unknown Source)
at
org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
... 4 more
Caused by:
java.io.EOFException
at
java.io.DataInputStream.readByte(DataInputStream.java:267)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
... 9 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242554#comment-17242554
]
Geode Integration commented on GEODE-8760:
--
Seen in [Benchmark_base
#490|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/490].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242555#comment-17242555
]
ASF GitHub Bot commented on GEODE-8755:
---
demery-pivotal commented on a change in pull request #5800:
URL: https://github.com/apache/geode/pull/5800#discussion_r534343409
##
File path:
geode-assembly/src/integrationTest/java/org/apache/geode/BundledJarsJUnitTest.java
##
@@ -67,7 +67,7 @@ public void verifyBundledJarsHaveNotChanged() throws
IOException {
sortedJars.entrySet().stream().map(entry ->
removeVersion(entry.getKey()));
Set bundledJarNames = new
TreeSet<>(lines.collect(Collectors.toSet()));
-Files.write(Paths.get("bundled_jars.txt"), bundledJarNames);
+Files.write(Paths.get("..", "bundled_jars.txt"), bundledJarNames);
Review comment:
Can you think of way to identify the tests that have this problem?
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
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242553#comment-17242553
]
Geode Integration commented on GEODE-8760:
--
Seen in [Benchmark_with_ssl
#487|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_with_ssl/builds/487].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242557#comment-17242557
]
ASF GitHub Bot commented on GEODE-8755:
---
demery-pivotal commented on a change in pull request #5800:
URL: https://github.com/apache/geode/pull/5800#discussion_r534356301
##
File path:
geode-assembly/src/integrationTest/java/org/apache/geode/BundledJarsJUnitTest.java
##
@@ -67,7 +67,7 @@ public void verifyBundledJarsHaveNotChanged() throws
IOException {
sortedJars.entrySet().stream().map(entry ->
removeVersion(entry.getKey()));
Set bundledJarNames = new
TreeSet<>(lines.collect(Collectors.toSet()));
-Files.write(Paths.get("bundled_jars.txt"), bundledJarNames);
+Files.write(Paths.get("..", "bundled_jars.txt"), bundledJarNames);
Review comment:
I did a scan of the integration test output to spot this kind of file. I
found AssemblyContentsIntegrationTest and GeodeDependencyJarIntegrationTest. I
will fix those. If you know of others, let me know.
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
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242558#comment-17242558
]
Geode Integration commented on GEODE-8573:
--
Seen in [DistributedTestOpenJDK11
#625|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/625]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0527/test-results/distributedTest/1606873826/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0527/test-artifacts/1606873826/distributedtestfiles-OpenJDK11-1.14.0-build.0527.tgz].
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242562#comment-17242562
]
ASF GitHub Bot commented on GEODE-8755:
---
yozaner1324 commented on a change in pull request #5800:
URL: https://github.com/apache/geode/pull/5800#discussion_r534359215
##
File path:
geode-assembly/src/integrationTest/java/org/apache/geode/BundledJarsJUnitTest.java
##
@@ -67,7 +67,7 @@ public void verifyBundledJarsHaveNotChanged() throws
IOException {
sortedJars.entrySet().stream().map(entry ->
removeVersion(entry.getKey()));
Set bundledJarNames = new
TreeSet<>(lines.collect(Collectors.toSet()));
-Files.write(Paths.get("bundled_jars.txt"), bundledJarNames);
+Files.write(Paths.get("..", "bundled_jars.txt"), bundledJarNames);
Review comment:
The three mentioned tests are the only ones I'm aware of that write
files that need to be accessed after the test runs. I searched for all other
occurrences of "Files.write" and none seemed important. I'm not sure there is a
better way to identify which files are important vs random temp files.
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
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8754) Deserialization Error in .NET DataInput::ReadObject
[ https://issues.apache.org/jira/browse/GEODE-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8754: -- Labels: pull-request-available (was: ) > Deserialization Error in .NET DataInput::ReadObject > --- > > Key: GEODE-8754 > URL: https://issues.apache.org/jira/browse/GEODE-8754 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > Using the IDataSerializable interface for user defined .NET types sometimes > fails in a Release build. Specifically, the DataInput::ReadObject() function > may fail in a Release build. > Note: DataInput::ReadObject() never fails in a Debug build. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8754) Deserialization Error in .NET DataInput::ReadObject
[ https://issues.apache.org/jira/browse/GEODE-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242563#comment-17242563 ] ASF GitHub Bot commented on GEODE-8754: --- mmartell opened a new pull request #704: URL: https://github.com/apache/geode-native/pull/704 This fixes an uninitialized variable in the clicache code (DataInput::ReadInternalObject). Also, added a new serialization test (CompositeClassWithClassAsKey) since there were no existing tests that executed this function. 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 > Deserialization Error in .NET DataInput::ReadObject > --- > > Key: GEODE-8754 > URL: https://issues.apache.org/jira/browse/GEODE-8754 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > > Using the IDataSerializable interface for user defined .NET types sometimes > fails in a Release build. Specifically, the DataInput::ReadObject() function > may fail in a Release build. > Note: DataInput::ReadObject() never fails in a Debug build. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8755) Content validator tests write output to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-8755:
--
Summary: Content validator tests write output to wrong dir (was:
BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir)
> Content validator tests write output to wrong dir
> -
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8755) Content validator tests write output to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-8755:
--
Description:
BundledJarsJUnitTest, {{AssemblyContentsIntegrationTest}}, and
{{GeodeDependencyJarIntegrationTest}} instruct the user to examine and vet the
content they have written to files in the
{{geode-assembly/build/integrationTest/}} dir.
But since GEODE-8637, which causes each test class to run in a unique working
directory, the files now end up in a directory other than the one in the
instructions, like:
{{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
This is confusing.
was:
BundledJarsJUnitTest instructs the user to examine and vet the
{{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
But since GEODE-8637, which causes each test class to run in a unique working
directory, the file now ends up in a directory other than the one in the
instructions, like:
{{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
This is confusing.
> Content validator tests write output to wrong dir
> -
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> BundledJarsJUnitTest, {{AssemblyContentsIntegrationTest}}, and
> {{GeodeDependencyJarIntegrationTest}} instruct the user to examine and vet
> the content they have written to files in the
> {{geode-assembly/build/integrationTest/}} dir.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the files now end up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8754) Deserialization Error in .NET DataInput::ReadObject
[ https://issues.apache.org/jira/browse/GEODE-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242589#comment-17242589 ] ASF GitHub Bot commented on GEODE-8754: --- lgtm-com[bot] commented on pull request #704: URL: https://github.com/apache/geode-native/pull/704#issuecomment-737409611 This pull request **introduces 4 alerts** when merging 2b2e3887f9b647963e14178e08f5f8a9d7d2a7fe into 5f14294535b0e90be01d5587f76f3ec9d0102e81 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-a8386920d9a7f0618c9e17fa8ad68a55772b6160) **new alerts:** * 4 for Dereferenced variable may be null 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 > Deserialization Error in .NET DataInput::ReadObject > --- > > Key: GEODE-8754 > URL: https://issues.apache.org/jira/browse/GEODE-8754 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > Using the IDataSerializable interface for user defined .NET types sometimes > fails in a Release build. Specifically, the DataInput::ReadObject() function > may fail in a Release build. > Note: DataInput::ReadObject() never fails in a Debug build. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8758) Downgrade testcontainers from 1.15.0 to 1.14.3
[ https://issues.apache.org/jira/browse/GEODE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242608#comment-17242608 ] ASF GitHub Bot commented on GEODE-8758: --- jdeppe-pivotal merged pull request #5804: URL: https://github.com/apache/geode/pull/5804 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 > Downgrade testcontainers from 1.15.0 to 1.14.3 > -- > > Key: GEODE-8758 > URL: https://issues.apache.org/jira/browse/GEODE-8758 > Project: Geode > Issue Type: Test > Components: build, redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > There appears to be a problem with the latest version, causing acceptance > tests to hang. > > Possibly this: > https://github.com/testcontainers/testcontainers-java/issues/3531 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8758) Downgrade testcontainers from 1.15.0 to 1.14.3
[ https://issues.apache.org/jira/browse/GEODE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-8758. --- Fix Version/s: 1.14.0 Resolution: Fixed > Downgrade testcontainers from 1.15.0 to 1.14.3 > -- > > Key: GEODE-8758 > URL: https://issues.apache.org/jira/browse/GEODE-8758 > Project: Geode > Issue Type: Test > Components: build, redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > There appears to be a problem with the latest version, causing acceptance > tests to hang. > > Possibly this: > https://github.com/testcontainers/testcontainers-java/issues/3531 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8758) Downgrade testcontainers from 1.15.0 to 1.14.3
[ https://issues.apache.org/jira/browse/GEODE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242610#comment-17242610 ] ASF subversion and git services commented on GEODE-8758: Commit 22a4e48fba0c5feb12965342af3aa2f8e26fcfa6 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=22a4e48 ] GEODE-8758: Downgrade testcontainers from 1.15.0 to 1.14.3 (#5804) > Downgrade testcontainers from 1.15.0 to 1.14.3 > -- > > Key: GEODE-8758 > URL: https://issues.apache.org/jira/browse/GEODE-8758 > Project: Geode > Issue Type: Test > Components: build, redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > There appears to be a problem with the latest version, causing acceptance > tests to hang. > > Possibly this: > https://github.com/testcontainers/testcontainers-java/issues/3531 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8641) CI Failure: PartitionedIndexedQueryBenchmark.run
[
https://issues.apache.org/jira/browse/GEODE-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-8641.
--
Resolution: Duplicate
> CI Failure: PartitionedIndexedQueryBenchmark.run
>
>
> Key: GEODE-8641
> URL: https://issues.apache.org/jira/browse/GEODE-8641
> Project: Geode
> Issue Type: Test
> Components: benchmarks, tests
>Reporter: Jens Deppe
>Priority: Major
>
> Benchmarking looks like some internal error:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/406
> {noformat}
> org.apache.geode.benchmark.tests.PartitionedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7860) Unmarshalling exception in Benchmark test with EOFException as cause
[
https://issues.apache.org/jira/browse/GEODE-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-7860.
--
Resolution: Duplicate
> Unmarshalling exception in Benchmark test with EOFException as cause
>
>
> Key: GEODE-7860
> URL: https://issues.apache.org/jira/browse/GEODE-7860
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, querying
>Reporter: Donal Evans
>Priority: Major
>
> {noformat}
> org.apache.geode.benchmark.tests.ReplicatedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> org.apache.geode.benchmark.tests.PartitionedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> {noformat}
> Failure seen in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/146
> but was passing in the following run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
[
https://issues.apache.org/jira/browse/GEODE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242611#comment-17242611
]
ASF GitHub Bot commented on GEODE-8752:
---
demery-pivotal merged pull request #5797:
URL: https://github.com/apache/geode/pull/5797
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
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses wrong address to revoke
> ---
>
> Key: GEODE-8752
> URL: https://issues.apache.org/jira/browse/GEODE-8752
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses the wrong address to revoke persistent members.
> The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
> Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
> address to revoke, but in some circumstances that can return an in
> appropriate address.
> GEODE-7029 changed the test to use a different mechanism to find the address
> to revoke: Walk through all available addresses on all available interfaces
> to find a non-loopback IPv4 address. But in some circumstances that can
> return an address other than the one used in the to-be-revoked member's ID,
> and the test fails.
> Both of these methods of getting the revoke address rest on unwarranted
> assumptions. The test should instead query the member to discover the address
> used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
[
https://issues.apache.org/jira/browse/GEODE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242612#comment-17242612
]
ASF subversion and git services commented on GEODE-8752:
Commit b8cc101a9bd95b68d3f5fe939060f08c698dc1c7 in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b8cc101 ]
GEODE-8752: Revoke using member's actual address (#5797)
When revoking a persistent member,
PersistentPartitionedRegionDistributedTest now uses the to-be-revoked
member's actual inet address in the revocation pattern.
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses wrong address to revoke
> ---
>
> Key: GEODE-8752
> URL: https://issues.apache.org/jira/browse/GEODE-8752
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses the wrong address to revoke persistent members.
> The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
> Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
> address to revoke, but in some circumstances that can return an in
> appropriate address.
> GEODE-7029 changed the test to use a different mechanism to find the address
> to revoke: Walk through all available addresses on all available interfaces
> to find a non-loopback IPv4 address. But in some circumstances that can
> return an address other than the one used in the to-be-revoked member's ID,
> and the test fails.
> Both of these methods of getting the revoke address rest on unwarranted
> assumptions. The test should instead query the member to discover the address
> used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8761) Add ServerConnection threads to ThreadMonitoring Service
Anilkumar Gingade created GEODE-8761: Summary: Add ServerConnection threads to ThreadMonitoring Service Key: GEODE-8761 URL: https://issues.apache.org/jira/browse/GEODE-8761 Project: Geode Issue Type: Improvement Components: regions Affects Versions: 1.14.0 Reporter: Anilkumar Gingade In Geode the Thread Monitoring Service (TMS) allows to monitor a thread to see if a thread is stuck doing particular operation; it provides thread dump of stuck thread after configured time. This ticket is to add ServerConnection threads to be monitored by TMS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8761) Add ServerConnection threads to ThreadMonitoring Service
[ https://issues.apache.org/jira/browse/GEODE-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade reassigned GEODE-8761: Assignee: Darrel Schneider > Add ServerConnection threads to ThreadMonitoring Service > > > Key: GEODE-8761 > URL: https://issues.apache.org/jira/browse/GEODE-8761 > Project: Geode > Issue Type: Improvement > Components: regions >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > In Geode the Thread Monitoring Service (TMS) allows to monitor a thread to > see if a thread is stuck doing particular operation; it provides thread dump > of stuck thread after configured time. This ticket is to add ServerConnection > threads to be monitored by TMS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8761) Add ServerConnection threads to ThreadMonitoring Service
[ https://issues.apache.org/jira/browse/GEODE-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-8761: - Labels: GeodeOperationAPI (was: ) > Add ServerConnection threads to ThreadMonitoring Service > > > Key: GEODE-8761 > URL: https://issues.apache.org/jira/browse/GEODE-8761 > Project: Geode > Issue Type: Improvement > Components: regions >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI > > In Geode the Thread Monitoring Service (TMS) allows to monitor a thread to > see if a thread is stuck doing particular operation; it provides thread dump > of stuck thread after configured time. This ticket is to add ServerConnection > threads to be monitored by TMS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
[
https://issues.apache.org/jira/browse/GEODE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-8752.
---
Resolution: Fixed
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses wrong address to revoke
> ---
>
> Key: GEODE-8752
> URL: https://issues.apache.org/jira/browse/GEODE-8752
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.14.0
>
>
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses the wrong address to revoke persistent members.
> The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
> Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
> address to revoke, but in some circumstances that can return an in
> appropriate address.
> GEODE-7029 changed the test to use a different mechanism to find the address
> to revoke: Walk through all available addresses on all available interfaces
> to find a non-loopback IPv4 address. But in some circumstances that can
> return an address other than the one used in the to-be-revoked member's ID,
> and the test fails.
> Both of these methods of getting the revoke address rest on unwarranted
> assumptions. The test should instead query the member to discover the address
> used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
[
https://issues.apache.org/jira/browse/GEODE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery closed GEODE-8752.
-
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses wrong address to revoke
> ---
>
> Key: GEODE-8752
> URL: https://issues.apache.org/jira/browse/GEODE-8752
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.14.0
>
>
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses the wrong address to revoke persistent members.
> The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
> Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
> address to revoke, but in some circumstances that can return an in
> appropriate address.
> GEODE-7029 changed the test to use a different mechanism to find the address
> to revoke: Walk through all available addresses on all available interfaces
> to find a non-loopback IPv4 address. But in some circumstances that can
> return an address other than the one used in the to-be-revoked member's ID,
> and the test fails.
> Both of these methods of getting the revoke address rest on unwarranted
> assumptions. The test should instead query the member to discover the address
> used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8762) Thread Monitoring Service to include reply waiting member info as part of stuck thread details
Anilkumar Gingade created GEODE-8762: Summary: Thread Monitoring Service to include reply waiting member info as part of stuck thread details Key: GEODE-8762 URL: https://issues.apache.org/jira/browse/GEODE-8762 Project: Geode Issue Type: Improvement Components: regions Affects Versions: 1.14.0 Reporter: Anilkumar Gingade Thread Monitoring Service provides information about the stuck thread with their stack dump. It will be nice to have information about the members a thread is waiting response from as part of the stuck thread details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8762) Thread Monitoring Service to include reply waiting member info as part of stuck thread details
[ https://issues.apache.org/jira/browse/GEODE-8762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade reassigned GEODE-8762: Assignee: Darrel Schneider > Thread Monitoring Service to include reply waiting member info as part of > stuck thread details > -- > > Key: GEODE-8762 > URL: https://issues.apache.org/jira/browse/GEODE-8762 > Project: Geode > Issue Type: Improvement > Components: regions >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > Thread Monitoring Service provides information about the stuck thread with > their stack dump. It will be nice to have information about the members a > thread is waiting response from as part of the stuck thread details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
[
https://issues.apache.org/jira/browse/GEODE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-8752:
--
Fix Version/s: 1.14.0
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses wrong address to revoke
> ---
>
> Key: GEODE-8752
> URL: https://issues.apache.org/jira/browse/GEODE-8752
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.14.0
>
>
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses the wrong address to revoke persistent members.
> The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
> Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
> address to revoke, but in some circumstances that can return an in
> appropriate address.
> GEODE-7029 changed the test to use a different mechanism to find the address
> to revoke: Walk through all available addresses on all available interfaces
> to find a non-loopback IPv4 address. But in some circumstances that can
> return an address other than the one used in the to-be-revoked member's ID,
> and the test fails.
> Both of these methods of getting the revoke address rest on unwarranted
> assumptions. The test should instead query the member to discover the address
> used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8762) Thread Monitoring Service to include reply waiting member info as part of stuck thread details
[ https://issues.apache.org/jira/browse/GEODE-8762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-8762: - Labels: GeodeOperationAPI (was: ) > Thread Monitoring Service to include reply waiting member info as part of > stuck thread details > -- > > Key: GEODE-8762 > URL: https://issues.apache.org/jira/browse/GEODE-8762 > Project: Geode > Issue Type: Improvement > Components: regions >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI > > Thread Monitoring Service provides information about the stuck thread with > their stack dump. It will be nice to have information about the members a > thread is waiting response from as part of the stuck thread details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8763) Benchmark CI only runs tests 4 times
[ https://issues.apache.org/jira/browse/GEODE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helena Bales reassigned GEODE-8763: --- Assignee: Helena Bales > Benchmark CI only runs tests 4 times > > > Key: GEODE-8763 > URL: https://issues.apache.org/jira/browse/GEODE-8763 > Project: Geode > Issue Type: Bug > Components: benchmarks, ci >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > > The benchmark has a retry mechanism that is supposed to run all tests, then > rerun any failed tests. If tests are still failing then it should retry those > tests, for a total of 5 test runs (including the first run of all the tests). > Currently it only runs the tests a total of 4 times. > Increase the number of runs to 5 to increase the tolerance for variance in > tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8763) Benchmark CI only runs tests 4 times
Helena Bales created GEODE-8763: --- Summary: Benchmark CI only runs tests 4 times Key: GEODE-8763 URL: https://issues.apache.org/jira/browse/GEODE-8763 Project: Geode Issue Type: Bug Components: benchmarks, ci Reporter: Helena Bales The benchmark has a retry mechanism that is supposed to run all tests, then rerun any failed tests. If tests are still failing then it should retry those tests, for a total of 5 test runs (including the first run of all the tests). Currently it only runs the tests a total of 4 times. Increase the number of runs to 5 to increase the tolerance for variance in tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8763) Benchmark CI only runs tests 4 times
[ https://issues.apache.org/jira/browse/GEODE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8763: -- Labels: pull-request-available (was: ) > Benchmark CI only runs tests 4 times > > > Key: GEODE-8763 > URL: https://issues.apache.org/jira/browse/GEODE-8763 > Project: Geode > Issue Type: Bug > Components: benchmarks, ci >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > > The benchmark has a retry mechanism that is supposed to run all tests, then > rerun any failed tests. If tests are still failing then it should retry those > tests, for a total of 5 test runs (including the first run of all the tests). > Currently it only runs the tests a total of 4 times. > Increase the number of runs to 5 to increase the tolerance for variance in > tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242629#comment-17242629
]
ASF GitHub Bot commented on GEODE-8742:
---
DonalEvans commented on a change in pull request #5803:
URL: https://github.com/apache/geode/pull/5803#discussion_r534410662
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/wancommand/ListGatewaysCommandDUnitTest.java
##
@@ -452,8 +452,10 @@ public void
testListGatewaysReceiversOnlyFalseAndSendersOnlyFalseReturnsSendersA
@Test
public void testListGatewaysWithOneDispatcherThread() {
-String command =
-"create gateway-sender --id=ln_Serial --remote-distributed-system-id=2
--dispatcher-threads=1";
+String command = CliStrings.CREATE_GATEWAYSENDER + " --" +
CliStrings.CREATE_GATEWAYSENDER__ID
Review comment:
If you use the `CommandStringBuilder` class with the `addOption()`
method, you can avoid having to manually put in the dashes and equals signs,
like so:
```
String command = new CommandStringBuilder(CREATE_GATEWAYSENDER)
.addOption(CREATE_GATEWAYSENDER__ID, "ln_Serial")
.addOption(CREATE_GATEWAYSENDER__REMOTEDISTRIBUTEDSYSTEMID, "2")
.addOption(CREATE_GATEWAYSENDER__DISPATCHERTHREADS, "1")
.getCommandString();
```
This helps make commands easier to read and reduces the chance of typos when
writing them.
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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8763) Benchmark CI only runs tests 4 times
[ https://issues.apache.org/jira/browse/GEODE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242630#comment-17242630 ] ASF GitHub Bot commented on GEODE-8763: --- nonbinaryprogrammer opened a new pull request #5806: URL: https://github.com/apache/geode/pull/5806 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 > Benchmark CI only runs tests 4 times > > > Key: GEODE-8763 > URL: https://issues.apache.org/jira/browse/GEODE-8763 > Project: Geode > Issue Type: Bug > Components: benchmarks, ci >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > > The benchmark has a retry mechanism that is supposed to run all tests, then > rerun any failed tests. If tests are still failing then it should retry those > tests, for a total of 5 test runs (including the first run of all the tests). > Currently it only runs the tests a total of 4 times. > Increase the number of runs to 5 to increase the tolerance for variance in > tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8747) Collect library dependencies into single dependency
[
https://issues.apache.org/jira/browse/GEODE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242653#comment-17242653
]
ASF GitHub Bot commented on GEODE-8747:
---
yozaner1324 opened a new pull request #5807:
URL: https://github.com/apache/geode/pull/5807
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
> Collect library dependencies into single dependency
> ---
>
> Key: GEODE-8747
> URL: https://issues.apache.org/jira/browse/GEODE-8747
> Project: Geode
> Issue Type: New Feature
> Components: build
>Reporter: Udo Kohlmeyer
>Assignee: Patrick Johnson
>Priority: Major
>
> Library dependencies like Spring, Jackson, Spring Security, etc. usually have
> many dependencies. Which if used within a module, require the listing each of
> these dependencies.
> With the addition of ClassLoader Isolation a need arose, where these
> libraries where loaded into a single ClassLoader, instead of being loaded by
> the ClassLoaders of each of the modules that depended on these libraries.
> This feature is to replace the following:
> {code:groovy}
> implementation('org.springframework:spring-core')
> implementation('org.springframework:spring-beans')
> implementation('org.springframework:spring-context')
> implementation('org.springframework:spring-jcl')
> implementation('org.springframework:spring-web')
> implementation('org.springframework.shell:spring-shell')
> {code}
> with a single entry:
> {code:groovy}
>implementation(project(':frameworks:springframework'))
> {code}
> What this new construct allows for is a pattern closer to "using a framework"
> without having to explicitly define all the library dependencies. In this
> approach, we "use" a framework library, rather than knowing all of the
> internal dependencies.
> With this change, the ClassLoader isolation work, will only load each
> dependency once.
> Currently identified dependencies that require to be loaded only once are:
> Spring and Jackson
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8747) Collect library dependencies into single dependency
[
https://issues.apache.org/jira/browse/GEODE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8747:
--
Labels: pull-request-available (was: )
> Collect library dependencies into single dependency
> ---
>
> Key: GEODE-8747
> URL: https://issues.apache.org/jira/browse/GEODE-8747
> Project: Geode
> Issue Type: New Feature
> Components: build
>Reporter: Udo Kohlmeyer
>Assignee: Patrick Johnson
>Priority: Major
> Labels: pull-request-available
>
> Library dependencies like Spring, Jackson, Spring Security, etc. usually have
> many dependencies. Which if used within a module, require the listing each of
> these dependencies.
> With the addition of ClassLoader Isolation a need arose, where these
> libraries where loaded into a single ClassLoader, instead of being loaded by
> the ClassLoaders of each of the modules that depended on these libraries.
> This feature is to replace the following:
> {code:groovy}
> implementation('org.springframework:spring-core')
> implementation('org.springframework:spring-beans')
> implementation('org.springframework:spring-context')
> implementation('org.springframework:spring-jcl')
> implementation('org.springframework:spring-web')
> implementation('org.springframework.shell:spring-shell')
> {code}
> with a single entry:
> {code:groovy}
>implementation(project(':frameworks:springframework'))
> {code}
> What this new construct allows for is a pattern closer to "using a framework"
> without having to explicitly define all the library dependencies. In this
> approach, we "use" a framework library, rather than knowing all of the
> internal dependencies.
> With this change, the ClassLoader isolation work, will only load each
> dependency once.
> Currently identified dependencies that require to be loaded only once are:
> Spring and Jackson
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8754) Deserialization Error in .NET DataInput::ReadObject
[
https://issues.apache.org/jira/browse/GEODE-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242654#comment-17242654
]
ASF GitHub Bot commented on GEODE-8754:
---
echobravopapa commented on a change in pull request #704:
URL: https://github.com/apache/geode-native/pull/704#discussion_r534420160
##
File path: tests/javaobject/cli/TestClassC.java
##
@@ -0,0 +1,114 @@
+/*
+ * 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 javaobject.cli;
+
+import java.util.*;
+import java.io.*;
+import org.apache.geode.*;
+import org.apache.geode.cache.Declarable;
+
+public class TestClassC implements Declarable, Serializable, DataSerializable {
+ private String Color;
+ private String Make;
+ private int Year;
+
+ static {
+ Instantiator.register(new Instantiator(javaobject.cli.TestClassC.class,
(byte) 102) {
+ public DataSerializable newInstance() {
+return new TestClassC();
+ }
+ });
+ }
+
+
+
+/*
Review comment:
dead code, pls remove
##
File path: clicache/src/DataInput.cpp
##
@@ -657,7 +657,7 @@ namespace Apache
//Log::Debug("DataInput::ReadInternalObject m_cursor " + m_cursor);
bool findinternal = false;
int8_t typeId = ReadByte();
- System::Int64 compId;
+ System::Int64 compId = 0;
Review comment:
RAII FTW?!?
##
File path: clicache/integration-test2/SerializationTests.cs
##
@@ -25,7 +26,335 @@
namespace Apache.Geode.Client.IntegrationTests
{
-public class Order : IDataSerializable
+ public class TestClassA : IDataSerializable
+ {
+ public int Id { get; set; }
+ public string Name { get; set; }
+ public short NumSides { get; set; }
+
+ // A default constructor is required for deserialization
+ public TestClassA() { }
+
+ public TestClassA(int id, string name, short numSides)
+ {
+ Id = id;
+ Name = name;
+ NumSides = numSides;
+ }
+
+ public override string ToString()
+ {
+ return string.Format("TestClassA: [{0}, {1}, {2}]", Id,
Name, NumSides);
+ }
+
+ public void ToData(DataOutput output)
+ {
+ output.WriteInt32(Id);
+ output.WriteUTF(Name);
+ output.WriteInt16(NumSides);
+ }
+
+ public void FromData(DataInput input)
+ {
+ Id = input.ReadInt32();
+ Name = input.ReadUTF();
+ NumSides = input.ReadInt16();
+ }
+
+ public ulong ObjectSize
+ {
+ get { return 0; }
+ }
+
+ public static ISerializable CreateDeserializable()
+ {
+ return new TestClassA();
+ }
+
+ public override bool Equals(object obj)
+ {
+ if (obj == null)
+ return false;
+ if (obj == this)
+ return true;
+
+ var other = obj as TestClassA;
+
+ if (Id == other.Id &&
+ Name == other.Name &&
+ NumSides == other.NumSides)
+ return true;
+ else
+ return false;
+ }
+
+ public override int GetHashCode()
+ {
+ return base.GetHashCode();
+ }
+ }
+
+ public class TestClassB : IDataSerializable
+ {
+ public int Width { get; set; }
+ public int Height { get; set; }
+ public string Name { get; set; }
+
+ // A default constructor is required for deserialization
+ public TestClassB() { }
+
+ p
[jira] [Commented] (GEODE-8748) Altering expiry time on proxy region causes NPE
[ https://issues.apache.org/jira/browse/GEODE-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242681#comment-17242681 ] ASF GitHub Bot commented on GEODE-8748: --- nabarunnag merged pull request #5790: URL: https://github.com/apache/geode/pull/5790 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 > Altering expiry time on proxy region causes NPE > --- > > Key: GEODE-8748 > URL: https://issues.apache.org/jira/browse/GEODE-8748 > Project: Geode > Issue Type: Task > Components: expiration >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > When we execute > "create region --name=region --type=PARTITION_PROXY --group=proxy" > "alter region --name=region --entry-time-to-live-expiration=1000 > --entry-time-to-live-expiration-action=destroy --group=proxy" > > This results in an NPE. Also if there is a mixture of proxy and non-proxy > versions of the same region and we could alter some of the non-proxy but the > proxy region failed on alter commands, then restarts will start encountering > problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8748) Altering expiry time on proxy region causes NPE
[ https://issues.apache.org/jira/browse/GEODE-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242682#comment-17242682 ] ASF subversion and git services commented on GEODE-8748: Commit a39c200fe9f68d3a1707a2f4af12729ac833074f in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a39c200 ] GEODE-8748: Prevents NPE on alter expiry on proxy regions (#5790) * When a region is created with zero local memory, there is no bucket regions created. * When alter region is called on this proxy region to alter expiry, it tries to manipulate the bucket region. * But there are no buckets and hence NPE is thrown. * In this commit a null check is done before alter the bucket regions. * Configs still need to changed to prevent restart issues. * This similar to the check done in setEntryTimeToLive in PartitionedRegion class > Altering expiry time on proxy region causes NPE > --- > > Key: GEODE-8748 > URL: https://issues.apache.org/jira/browse/GEODE-8748 > Project: Geode > Issue Type: Task > Components: expiration >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > When we execute > "create region --name=region --type=PARTITION_PROXY --group=proxy" > "alter region --name=region --entry-time-to-live-expiration=1000 > --entry-time-to-live-expiration-action=destroy --group=proxy" > > This results in an NPE. Also if there is a mixture of proxy and non-proxy > versions of the same region and we could alter some of the non-proxy but the > proxy region failed on alter commands, then restarts will start encountering > problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242736#comment-17242736
]
ASF GitHub Bot commented on GEODE-8742:
---
mkevo commented on a change in pull request #5803:
URL: https://github.com/apache/geode/pull/5803#discussion_r534489795
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/wancommand/ListGatewaysCommandDUnitTest.java
##
@@ -452,8 +452,10 @@ public void
testListGatewaysReceiversOnlyFalseAndSendersOnlyFalseReturnsSendersA
@Test
public void testListGatewaysWithOneDispatcherThread() {
-String command =
-"create gateway-sender --id=ln_Serial --remote-distributed-system-id=2
--dispatcher-threads=1";
+String command = CliStrings.CREATE_GATEWAYSENDER + " --" +
CliStrings.CREATE_GATEWAYSENDER__ID
Review comment:
Nice! I take a look on test above, so I do on this way, but this
proposal is better.
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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242774#comment-17242774
]
ASF subversion and git services commented on GEODE-8697:
Commit acae4bb3fa8e4a20f0bad8eb63259eb1b6d79fa3 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=acae4bb ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
(cherry picked from commit 403e19c0a2b85369274e8254c16e0ae508b82e94)
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> 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:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geo
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242775#comment-17242775
]
ASF subversion and git services commented on GEODE-8697:
Commit acae4bb3fa8e4a20f0bad8eb63259eb1b6d79fa3 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=acae4bb ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
(cherry picked from commit 403e19c0a2b85369274e8254c16e0ae508b82e94)
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> 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:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geo
[jira] [Updated] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8697:
--
Fix Version/s: 1.13.2
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0, 1.13.2
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> 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:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.partitioned.FetchKeysMessage$FetchKeysResponse.waitForKeys(FetchKeysMessage.java:584)
> at
> org.apache.geode.internal.cache.PartitionedRegion.getBucketKeys(PartitionedRegion.java:4463)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataView.getBucketKeys(PartitionedRegionDataView.java:118)
> at
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.getNextBucketIte
[jira] [Commented] (GEODE-8532) Parse chunked replies in gnmsg tool
[ https://issues.apache.org/jira/browse/GEODE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242779#comment-17242779 ] ASF subversion and git services commented on GEODE-8532: Commit fc29918251d6aef9fea8233a1268fd8a80aec644 in geode's branch refs/heads/feature/GEODE-8532 from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fc29918 ] GEODE-8532: Corrected the geode-tcp-server jar name in doc > Parse chunked replies in gnmsg tool > --- > > Key: GEODE-8532 > URL: https://issues.apache.org/jira/browse/GEODE-8532 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > As a native client developer, I would like to be able to see all reply > messages from server to client when debugging with gnmsg. I can, in fact, > see replies/responses when they come back in a "complete" message, but at > present when a response is "chunked" gnmsg ignores it, so things like, for > example, `getAll()` responses don't show up in the message dump. This is > probably a complex task, and may require logging more data for chunk > responses in the C++ native client code, but it's important. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8532) Parse chunked replies in gnmsg tool
[ https://issues.apache.org/jira/browse/GEODE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242780#comment-17242780 ] ASF GitHub Bot commented on GEODE-8532: --- nabarunnag opened a new pull request #5808: URL: https://github.com/apache/geode/pull/5808 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 > Parse chunked replies in gnmsg tool > --- > > Key: GEODE-8532 > URL: https://issues.apache.org/jira/browse/GEODE-8532 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > As a native client developer, I would like to be able to see all reply > messages from server to client when debugging with gnmsg. I can, in fact, > see replies/responses when they come back in a "complete" message, but at > present when a response is "chunked" gnmsg ignores it, so things like, for > example, `getAll()` responses don't show up in the message dump. This is > probably a complex task, and may require logging more data for chunk > responses in the C++ native client code, but it's important. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8721) member that should become coordinator never detects loss of current coordinator
[
https://issues.apache.org/jira/browse/GEODE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242785#comment-17242785
]
ASF subversion and git services commented on GEODE-8721:
Commit 0f23c7643d8410cba0badbb126946869d36f4523 in geode's branch
refs/heads/support/1.12 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f23c76 ]
GEODE-8721: member that should become coordinator never detects loss of current
coordinator (#5758)
* GEODE-8721: member that should become coordinator never detects loss of
current coordinator
If a server is in the process of performing an availability check on
another server we shouldn't update the contact timestamp for
the suspected server based on gossip from another server. Doing so
will make the availability check pass and send out another gossip
message that would likewise update their timestamps for the suspected
server, perpetuating the notion that the suspect is still around.
* added VisibleForTesting
(cherry picked from commit b7afc604b9c2fafe4388dcdcf05fc7ec49c0ce86)
> member that should become coordinator never detects loss of current
> coordinator
> ---
>
> Key: GEODE-8721
> URL: https://issues.apache.org/jira/browse/GEODE-8721
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available, release-blocker
> Fix For: 1.12.1, 1.14.0, 1.13.2
>
>
> During a network partition a server that should have become membership
> coordinator and shut down its side of the partition never detected the loss
> of a server on the other side of the partition. Instead it continually
> performed availability checks on that other server and the checks passed.
> Its log file had continually increasing timestamps for when it claimed the
> other server had contacted it, which was not possible due to the network
> partition (which was formed through iptable manipulation).
> At least one other server on its side of the network partition was doing the
> same thing. It looks like they were interfering with each others
> availability checks in some way.
> {noformat}
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.227 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:12 PDT 2020
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.228 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25995/system.log: [info 2020/10/20 22:23:16.229 PDT receiver,rs-F21040449a0i3large-72-61636> tid=0x23] No longer suspecting
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.212 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:14 PDT 2020
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.213 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> locatorp1_26023/system.log: [info 2020/10/20 22:23:17.232 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25998/system.log: [info 2020/10/20 22:23:18.215 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25995/system.log: [info 2020/10/20 22:23:21.006 PDT Timer-2,rs-F21040449a0i3large-72-61636> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:16 PDT 2020
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8721) member that should become coordinator never detects loss of current coordinator
[
https://issues.apache.org/jira/browse/GEODE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242786#comment-17242786
]
ASF subversion and git services commented on GEODE-8721:
Commit 0f23c7643d8410cba0badbb126946869d36f4523 in geode's branch
refs/heads/support/1.12 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f23c76 ]
GEODE-8721: member that should become coordinator never detects loss of current
coordinator (#5758)
* GEODE-8721: member that should become coordinator never detects loss of
current coordinator
If a server is in the process of performing an availability check on
another server we shouldn't update the contact timestamp for
the suspected server based on gossip from another server. Doing so
will make the availability check pass and send out another gossip
message that would likewise update their timestamps for the suspected
server, perpetuating the notion that the suspect is still around.
* added VisibleForTesting
(cherry picked from commit b7afc604b9c2fafe4388dcdcf05fc7ec49c0ce86)
> member that should become coordinator never detects loss of current
> coordinator
> ---
>
> Key: GEODE-8721
> URL: https://issues.apache.org/jira/browse/GEODE-8721
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available, release-blocker
> Fix For: 1.12.1, 1.14.0, 1.13.2
>
>
> During a network partition a server that should have become membership
> coordinator and shut down its side of the partition never detected the loss
> of a server on the other side of the partition. Instead it continually
> performed availability checks on that other server and the checks passed.
> Its log file had continually increasing timestamps for when it claimed the
> other server had contacted it, which was not possible due to the network
> partition (which was formed through iptable manipulation).
> At least one other server on its side of the network partition was doing the
> same thing. It looks like they were interfering with each others
> availability checks in some way.
> {noformat}
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.227 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:12 PDT 2020
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.228 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25995/system.log: [info 2020/10/20 22:23:16.229 PDT receiver,rs-F21040449a0i3large-72-61636> tid=0x23] No longer suspecting
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.212 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:14 PDT 2020
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.213 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> locatorp1_26023/system.log: [info 2020/10/20 22:23:17.232 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25998/system.log: [info 2020/10/20 22:23:18.215 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25995/system.log: [info 2020/10/20 22:23:21.006 PDT Timer-2,rs-F21040449a0i3large-72-61636> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:16 PDT 2020
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8697:
--
Fix Version/s: 1.12.1
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.2
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> 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:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.partitioned.FetchKeysMessage$FetchKeysResponse.waitForKeys(FetchKeysMessage.java:584)
> at
> org.apache.geode.internal.cache.PartitionedRegion.getBucketKeys(PartitionedRegion.java:4463)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataView.getBucketKeys(PartitionedRegionDataView.java:118)
> at
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.getNextB
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242790#comment-17242790
]
ASF subversion and git services commented on GEODE-8697:
Commit 929852d16ac1b44c1c51d6b2c61d643bf4bdac64 in geode's branch
refs/heads/support/1.12 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=929852d ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
(cherry picked from commit 403e19c0a2b85369274e8254c16e0ae508b82e94)
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.2
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> 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:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242791#comment-17242791
]
ASF subversion and git services commented on GEODE-8697:
Commit 929852d16ac1b44c1c51d6b2c61d643bf4bdac64 in geode's branch
refs/heads/support/1.12 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=929852d ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
(cherry picked from commit 403e19c0a2b85369274e8254c16e0ae508b82e94)
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.2
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> 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:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
[jira] [Created] (GEODE-8764) Lucene Functions should request data read permission only on the specified region
Xiaojian Zhou created GEODE-8764: Summary: Lucene Functions should request data read permission only on the specified region Key: GEODE-8764 URL: https://issues.apache.org/jira/browse/GEODE-8764 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou GEODE-6930 changed the lucene functions' permission from ALL to only requiring DATA_READ. But it did not specified region. So it's actually requesting DATA_READ on all the regions. This definitely over requested. The lucene functions only need DATA_READ permission on specified region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8764) Lucene Functions should request data read permission only on the specified region
[ https://issues.apache.org/jira/browse/GEODE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-8764: Assignee: Xiaojian Zhou > Lucene Functions should request data read permission only on the specified > region > - > > Key: GEODE-8764 > URL: https://issues.apache.org/jira/browse/GEODE-8764 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > > GEODE-6930 changed the lucene functions' permission from ALL to only > requiring DATA_READ. But it did not specified region. So it's actually > requesting DATA_READ on all the regions. This definitely over requested. > The lucene functions only need DATA_READ permission on specified region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8764) Lucene Functions should request data read permission only on the specified region
[ https://issues.apache.org/jira/browse/GEODE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242859#comment-17242859 ] ASF GitHub Bot commented on GEODE-8764: --- gesterzhou opened a new pull request #5809: URL: https://github.com/apache/geode/pull/5809 … on the specified region 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 > Lucene Functions should request data read permission only on the specified > region > - > > Key: GEODE-8764 > URL: https://issues.apache.org/jira/browse/GEODE-8764 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > > GEODE-6930 changed the lucene functions' permission from ALL to only > requiring DATA_READ. But it did not specified region. So it's actually > requesting DATA_READ on all the regions. This definitely over requested. > The lucene functions only need DATA_READ permission on specified region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8764) Lucene Functions should request data read permission only on the specified region
[ https://issues.apache.org/jira/browse/GEODE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8764: -- Labels: pull-request-available (was: ) > Lucene Functions should request data read permission only on the specified > region > - > > Key: GEODE-8764 > URL: https://issues.apache.org/jira/browse/GEODE-8764 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > GEODE-6930 changed the lucene functions' permission from ALL to only > requiring DATA_READ. But it did not specified region. So it's actually > requesting DATA_READ on all the regions. This definitely over requested. > The lucene functions only need DATA_READ permission on specified region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8764) Lucene Functions should request data read permission only on the specified region
[ https://issues.apache.org/jira/browse/GEODE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242860#comment-17242860 ] ASF subversion and git services commented on GEODE-8764: Commit 5dce22ec90a79040418aa083e0daaf3d947871c7 in geode's branch refs/heads/feature/GEODE-8764 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5dce22e ] GEODE-8764: Lucene Functions should request data read permission only on the specified region > Lucene Functions should request data read permission only on the specified > region > - > > Key: GEODE-8764 > URL: https://issues.apache.org/jira/browse/GEODE-8764 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > GEODE-6930 changed the lucene functions' permission from ALL to only > requiring DATA_READ. But it did not specified region. So it's actually > requesting DATA_READ on all the regions. This definitely over requested. > The lucene functions only need DATA_READ permission on specified region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242939#comment-17242939
]
Geode Integration commented on GEODE-8191:
--
Seen in [DistributedTestOpenJDK11
#630|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/630]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0530/test-results/distributedTest/1606956466/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0530/test-artifacts/1606956466/distributedtestfiles-OpenJDK11-1.14.0-build.0530.tgz].
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.14.0
>
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242940#comment-17242940
]
Geode Integration commented on GEODE-8573:
--
Seen in [DistributedTestOpenJDK11
#629|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/629].
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8329) Durable CQ not registered as durable after server failover
[
https://issues.apache.org/jira/browse/GEODE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242969#comment-17242969
]
ASF GitHub Bot commented on GEODE-8329:
---
mkevo commented on pull request #5360:
URL: https://github.com/apache/geode/pull/5360#issuecomment-737718555
Hi @agingade ,
If you have any concerns please write them by the end of the week, if not we
will go with merging this.
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
> Durable CQ not registered as durable after server failover
> --
>
> Key: GEODE-8329
> URL: https://issues.apache.org/jira/browse/GEODE-8329
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
>
> {color:#172b4d}It seems that aftter server failover the java client is
> wrongly re-registering CQ on new server as not durable. Command *list
> durable-cq* prints that there are no durable CQ which is correct, since CQ is
> wrongly registered by client as not durable and therefore following
> printout:{color}
> {code:java}
> gfsh>list durable-cqs --durable-client-id=AppCounters
> Member | Status | CQ Name
> --- | --- |
> server1 | OK | randomTracker
> server2 | IGNORED | No client found with client-id : AppCounters
> server3 | IGNORED | No client found with client-id : AppCounters
>
> after shutdown of server1:
>
> gfsh>list durable-cqs --durable-client-id=AppCounters
> Member | Status | CQ Name
> --- | --- |
> ---
> server2 | IGNORED | No durable cqs found for durable-client-id :
> "AppCounters". --> server2 is hosting CQ, but it is not flagged as durable
> server3 | IGNORED | No client found with client-id : AppCounters{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8687) Durable client is continuously re-registering CQs on all servers when event de-serialization fails causing resource exhaustion on servers
[
https://issues.apache.org/jira/browse/GEODE-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242972#comment-17242972
]
ASF subversion and git services commented on GEODE-8687:
Commit 2e7e45699b74812038dc516aaf7c14621951090b in geode's branch
refs/heads/develop from Jakov Varenina
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2e7e456 ]
GEODE-8687: Fix for handling of PdxSerializationException on client (#5730)
* GEODE-8687: Improve handling of seralization error
* Improves handling of PdxSerializationException on client at the reception
of events from subscription queue
* Faulty behavior: At the reception of event for which
PdxSerializationException is thrown the client would always shutdown
CacheClientUpdater, destroy subscription queue connection
and try to perform failover to other server in cluster
* Behaviour with this fix: At the reception of event that provoke
PdxSerializationException client will only log the exception
* DurableClientCQAutoSerializer test updated
* Empty commit to trigger test
* Updates after review
> Durable client is continuously re-registering CQs on all servers when event
> de-serialization fails causing resource exhaustion on servers
> --
>
> Key: GEODE-8687
> URL: https://issues.apache.org/jira/browse/GEODE-8687
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.13.0
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Attachments: deserialzationFault.log
>
>
> When ReflectionBasedAutoSerializer is wrongly/not set it results with
> serialization exception on client at the reception of the CQ events.
> Serialization exception isn't logged which is misleading, and is hard to find
> that actually ReflectionBasedAutoSerializer isn't set correctly. Only log
> that can be seen is that client/servers subscription connections are closed
> due to EOF. This is because client destroys subscriptions connections
> intentionally, but doesn't log reason (PdxSerializationException) that led to
> this. It would be good that serialization exceptions are logged as error or
> warn.
> Client destroys subscription connection and perform server fail-over whenever
> serialization issue occurs. Additionally when subscription connection for
> particular server fails multiple times then this server is put in deny list
> for 10 seconds (this is configurable with {{ping-interval}}). After 10s
> expire the server is removed from list and it is available for subscription
> connection which will be destroyed again due serialization issue. This will
> go indefinitely and approx. every 10s in this case the client subscribes to
> each servers at least once. Due to serialization issue events aren't sent to
> client and remain in subscription queues.
> Whenever connection fails due to serialization issue and client is not
> durable then subscription queue is closed and events are lost.
> The biggest problem arises when client is durable. This is because
> subscription queue remains on server for configurable period of time (e.g.
> 300s) waiting for client to reconnect. When client perform fail-over to
> another server it will create new subscription queue using initial image from
> old queue that is currently paused. This means that all events from old queue
> will be transferred to new subscription queue hosted by the current primary
> server. This will happen on all servers and all of them will have copy of the
> queue even subscription redundancy isn't configured. The problem here is that
> client will periodically (every 10s in this case) establish connection to
> each servers, so configured timeout (e.g. 300s) will never expire, but it
> will be renewed each time client is registered. This could cause a lots of
> problems since memory and disk usage (if overflow on queue is configured)
> will increase on all servers.
> You can find in attached logs for the problematic case with durable client :
> vm0 -> locator
> vm1, vm2 -> servers
> vm3 -> durable client with enabled subscription handling CQ
> events
> vm4 -> client generating traffic that should trigger registered
> CQ
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8687) Durable client is continuously re-registering CQs on all servers when event de-serialization fails causing resource exhaustion on servers
[
https://issues.apache.org/jira/browse/GEODE-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242971#comment-17242971
]
ASF subversion and git services commented on GEODE-8687:
Commit 2e7e45699b74812038dc516aaf7c14621951090b in geode's branch
refs/heads/develop from Jakov Varenina
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2e7e456 ]
GEODE-8687: Fix for handling of PdxSerializationException on client (#5730)
* GEODE-8687: Improve handling of seralization error
* Improves handling of PdxSerializationException on client at the reception
of events from subscription queue
* Faulty behavior: At the reception of event for which
PdxSerializationException is thrown the client would always shutdown
CacheClientUpdater, destroy subscription queue connection
and try to perform failover to other server in cluster
* Behaviour with this fix: At the reception of event that provoke
PdxSerializationException client will only log the exception
* DurableClientCQAutoSerializer test updated
* Empty commit to trigger test
* Updates after review
> Durable client is continuously re-registering CQs on all servers when event
> de-serialization fails causing resource exhaustion on servers
> --
>
> Key: GEODE-8687
> URL: https://issues.apache.org/jira/browse/GEODE-8687
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.13.0
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Attachments: deserialzationFault.log
>
>
> When ReflectionBasedAutoSerializer is wrongly/not set it results with
> serialization exception on client at the reception of the CQ events.
> Serialization exception isn't logged which is misleading, and is hard to find
> that actually ReflectionBasedAutoSerializer isn't set correctly. Only log
> that can be seen is that client/servers subscription connections are closed
> due to EOF. This is because client destroys subscriptions connections
> intentionally, but doesn't log reason (PdxSerializationException) that led to
> this. It would be good that serialization exceptions are logged as error or
> warn.
> Client destroys subscription connection and perform server fail-over whenever
> serialization issue occurs. Additionally when subscription connection for
> particular server fails multiple times then this server is put in deny list
> for 10 seconds (this is configurable with {{ping-interval}}). After 10s
> expire the server is removed from list and it is available for subscription
> connection which will be destroyed again due serialization issue. This will
> go indefinitely and approx. every 10s in this case the client subscribes to
> each servers at least once. Due to serialization issue events aren't sent to
> client and remain in subscription queues.
> Whenever connection fails due to serialization issue and client is not
> durable then subscription queue is closed and events are lost.
> The biggest problem arises when client is durable. This is because
> subscription queue remains on server for configurable period of time (e.g.
> 300s) waiting for client to reconnect. When client perform fail-over to
> another server it will create new subscription queue using initial image from
> old queue that is currently paused. This means that all events from old queue
> will be transferred to new subscription queue hosted by the current primary
> server. This will happen on all servers and all of them will have copy of the
> queue even subscription redundancy isn't configured. The problem here is that
> client will periodically (every 10s in this case) establish connection to
> each servers, so configured timeout (e.g. 300s) will never expire, but it
> will be renewed each time client is registered. This could cause a lots of
> problems since memory and disk usage (if overflow on queue is configured)
> will increase on all servers.
> You can find in attached logs for the problematic case with durable client :
> vm0 -> locator
> vm1, vm2 -> servers
> vm3 -> durable client with enabled subscription handling CQ
> events
> vm4 -> client generating traffic that should trigger registered
> CQ
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8687) Durable client is continuously re-registering CQs on all servers when event de-serialization fails causing resource exhaustion on servers
[
https://issues.apache.org/jira/browse/GEODE-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242970#comment-17242970
]
ASF GitHub Bot commented on GEODE-8687:
---
mkevo merged pull request #5730:
URL: https://github.com/apache/geode/pull/5730
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
> Durable client is continuously re-registering CQs on all servers when event
> de-serialization fails causing resource exhaustion on servers
> --
>
> Key: GEODE-8687
> URL: https://issues.apache.org/jira/browse/GEODE-8687
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.13.0
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Attachments: deserialzationFault.log
>
>
> When ReflectionBasedAutoSerializer is wrongly/not set it results with
> serialization exception on client at the reception of the CQ events.
> Serialization exception isn't logged which is misleading, and is hard to find
> that actually ReflectionBasedAutoSerializer isn't set correctly. Only log
> that can be seen is that client/servers subscription connections are closed
> due to EOF. This is because client destroys subscriptions connections
> intentionally, but doesn't log reason (PdxSerializationException) that led to
> this. It would be good that serialization exceptions are logged as error or
> warn.
> Client destroys subscription connection and perform server fail-over whenever
> serialization issue occurs. Additionally when subscription connection for
> particular server fails multiple times then this server is put in deny list
> for 10 seconds (this is configurable with {{ping-interval}}). After 10s
> expire the server is removed from list and it is available for subscription
> connection which will be destroyed again due serialization issue. This will
> go indefinitely and approx. every 10s in this case the client subscribes to
> each servers at least once. Due to serialization issue events aren't sent to
> client and remain in subscription queues.
> Whenever connection fails due to serialization issue and client is not
> durable then subscription queue is closed and events are lost.
> The biggest problem arises when client is durable. This is because
> subscription queue remains on server for configurable period of time (e.g.
> 300s) waiting for client to reconnect. When client perform fail-over to
> another server it will create new subscription queue using initial image from
> old queue that is currently paused. This means that all events from old queue
> will be transferred to new subscription queue hosted by the current primary
> server. This will happen on all servers and all of them will have copy of the
> queue even subscription redundancy isn't configured. The problem here is that
> client will periodically (every 10s in this case) establish connection to
> each servers, so configured timeout (e.g. 300s) will never expire, but it
> will be renewed each time client is registered. This could cause a lots of
> problems since memory and disk usage (if overflow on queue is configured)
> will increase on all servers.
> You can find in attached logs for the problematic case with durable client :
> vm0 -> locator
> vm1, vm2 -> servers
> vm3 -> durable client with enabled subscription handling CQ
> events
> vm4 -> client generating traffic that should trigger registered
> CQ
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
